From noreply@sourceforge.net  Wed Jan  1 08:21:16 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 00:21:16 -0800
Subject: [Patches] [ python-Patches-660618 ] math.loggamma(z)
Message-ID: <E18Te7o-0005As-00@sc8-sf-web3.sourceforge.net>

Patches item #660618, was opened at 2003-01-01 03:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660618&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Tim Peters (tim_one)
Summary: math.loggamma(z)

Initial Comment:
Add a function to compute ln(gamma(z)).  It's fast 
and easy to compute but is a major PITA when you 
need it and don't have it available.

It is useful by itself, for factorials, binomial 
coefficients, combinatorics, and for computing the 
beta function.

I'm not for growing the mathmodule by much, but 
this and an incomplete gamma are a fine pair of 
basic building blocks and belong in the tool chest.

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

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


From noreply@sourceforge.net  Wed Jan  1 09:53:15 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 01:53:15 -0800
Subject: [Patches] [ python-Patches-656590 ] /dev/ptmx support for ptys (cygwin)
Message-ID: <E18TfYp-0006HR-00@sc8-sf-web2.sourceforge.net>

Patches item #656590, was opened at 2002-12-20 02:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=656590&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Paul Swartz (z3p)
Assigned to: Neal Norwitz (nnorwitz)
Summary: /dev/ptmx support for ptys (cygwin)

Initial Comment:
On Cygwin (and I believe Solaris, but I'm not sure), ptys 
are allocated using /dev/ptmx.  This patch checks 
for /dev/ptmx, and if it exists and openpty and _getpty 
don't, it will open ptys using /dev/ptmx.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-01 10:53

Message:
Logged In: YES 
user_id=21627

I have now changed slave_open to push ptem and ldterm, and
autodetect stropts.h (which is the POSIX name of that
header), in

configure 1.372
configure.in 1.383
pyconfig.h.in 1.68
pty.py 1.13
NEWS 1.587
fcntlmodule.c 2.37
posixmodule.c 2.280


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 23:36

Message:
Logged In: YES 
user_id=33168

ttyname is similar: /dev/pts/6

I verified that I_PUSH is also (ord('S')<<8)|2

I tried doing this:

  import pty
  master_fd, slave_name = pty.master_open()
  slave_fd = pty.slave_open(slave_name)
  fcntl.ioctl.(slave_fd, ((ord('S')<<8)|2), "ptem")


But after the ioctl, I got:
  IOError: [Errno 22] Invalid argument


Is this what you were doing?  Does this work for you?  If
it's easier, we can do this through email too.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 22:07

Message:
Logged In: YES 
user_id=21627

What is the ttyname returned from master_open?

On Solaris, I noticed that the isatty call also fails, and
the device name is /dev/pts/<n>, where n in a number.
pts(7D) reveals that merely opening that device is not
sufficient: you also need to push "ptem" and "ldterm". In
fact, pushing ptem alone is sufficient to make isatty succeed.

Could you try  whether pushing those drivers in slave_open
changes the behaviour? Exposing I_PUSH isn't strictly
necessary for this; I_PUSH = ((ord('S')<<8)|2) worked fine
for me (after reading stropts.h).

If that works, I think we should expose the entire family of
I_ constants in fcntl, and try pushing the drivers in
slave_open; if I_PUSH is not present or pusing a driver
fails, we return the "raw" file descriptor.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 21:26

Message:
Logged In: YES 
user_id=33168

Here's what I've found so far.

The test does: pty.master_open() which does an openpty(),
but closes the slave_fd.  The test then reopens the slave by
doing pty.slave_open().  Calling isatty() on this fd causes
HPUX to hang.  Note:  master_open() and slave_open have been
deprecated since 2.0, if I'm reading CVS logs properly (1.4
of pty.py).  Neither is documented.

I have no idea specifically why the hang occurs.  There's no
strace/truss installed for tracing syscalls.  From gdb,
here's the stack trace:

#0  0x77f9e548 in _ioctl_sys () from /usr/lib/libc.2
#1  0x77f282f4 in isatty () from /usr/lib/libc.2
#2  0x14d484 in posix_isatty (self=0x0, args=0x4004fbd0)
    at ./Modules/posixmodule.c:5414


Using openpty() works just fine.  I'm not sure how to
proceed.  One option is to remove master_open() and
slave_open().  I don't know if this is good or not.  We can
certainly skip the isatty() part of the test on HPUX.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 19:21

Message:
Logged In: YES 
user_id=33168

Martin, I agree with everything you said.  I'm commenting
out the test for now.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 19:14

Message:
Logged In: YES 
user_id=21627

Ok, I have removed the test for the master from test_openpty 
1.8. As for the test hanging: can you perform strace/truss on 
that machine to see what it is doing? On Solaris, isatty 
translates to ioctl(fd, TCGETA, struct termio); a terminal is a 
file that supports this ioctl.

If we need a quick work-around for 2.3a1, I suggest to skip 
that test temporarily for hpux. I would not like to backout this 
change, as the code appears to be basically correct.

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

Comment By: Paul Swartz (z3p)
Date: 2002-12-31 19:10

Message:
Logged In: YES 
user_id=123843

The code comes from the OpenSSH pty handling code.  I 
can't see why isatty would be hanging, but I don't think 
O_NONBLOCK can hurt.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 18:57

Message:
Logged In: YES 
user_id=33168

The code seems to work, I can believe it's the test.  I
don't understand why isatty(slave_fd) hangs though.  Paul's
code is the same as the HPUX man page, with one exception
the man page doesn't use O_NOCTTY.  However, removing this
flag makes no difference.

Should we use O_NONBLOCK?  I haven't tried it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 18:52

Message:
Logged In: YES 
user_id=21627

I get the same on Solaris. Could it be that the test is
broken? Why should the master end be itself a terminal?

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

Comment By: Paul Swartz (z3p)
Date: 2002-12-31 18:48

Message:
Logged In: YES 
user_id=123843

The only thing that I can think of to try is on the slave end:

fd = os.open('/dev/tty', os.O_RDWR|os.O_NOCTTY)
if fd:
    fnctl.ioctl(fd, tty.TIOCNOTTY, '')
    close(fd)
fcntl.ioctl(slavefd, tty.TIOCSCTTY, '')

That should disconnect the slave from it's old controlling TTY 
and reconnect it to the new TTY.  (I'm not sure if it will come 
through, lines 3 and 4 are indented.)  Past this, I have no 
idea, as it works for me.

As for HPUX also needing sys/stropts.h, maybe adding a 
check for that file is a better idea then checking for sun/hpux.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 18:18

Message:
Logged In: YES 
user_id=33168

Paul, I had to modify the patch a bit to get posixmodule.c
to compile on HPUX11.  HPUX also needs sys/stropts.h for
I_PUSH and the macro is __hpux, not _hpux.

However, after making these changes, test_openpty fails: 
'Master-end of pty is not a terminal' and test_pty hangs
when doing:  if not os.isatty(slave_fd)

Any ideas?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 13:57

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

configure 1.371
configure.in 1.382
pyconfig.h.in 1.67
ACKS 1.221
NEWS 1.581
posixmodule.c 2.277


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

Comment By: Paul Swartz (z3p)
Date: 2002-12-27 20:13

Message:
Logged In: YES 
user_id=123843

Fixed to use __CYGWIN__.  I don't think doing forkpty in the 
same way is the right idea, given that pty.fork() does the 
same thing and is the "right" way to fork with ptys.  The 
openpty change is necessary because there is no way 
duplicate it from pure-python, whereas forkpty can be 
duplicated with openpty/fork.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-27 11:25

Message:
Logged In: YES 
user_id=21627

It is common in Python to check for cygwin by checking
whether __CYGWIN__ is defined, so there is no need to invent
another mechanism.

Also, could you work out patches for forkpty as well?

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

Comment By: Paul Swartz (z3p)
Date: 2002-12-21 19:23

Message:
Logged In: YES 
user_id=123843

I reconciled the openpty parts of the two patches, and have 
attached a new patch.  The only thing I wonder about is if 
there is a better way to check for Cygwin in posixmodule.  
Adding an extra define seems like the wrong way.

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

Comment By: Paul Swartz (z3p)
Date: 2002-12-21 17:49

Message:
Logged In: YES 
user_id=123843

I took a look at the other patch, and back at the OpenSSH 
pty code (where I got the idea).  The pushes are in an '#ifndef 
CYGWIN' in OpenSSH, and the ioctl for ttcompant is in 
an '#ifndef _hpux'.  Not changing the SIGCHLD handler didn't 
break the cygwin code, but I doubt adding that would break 
things.  I'll work on combining the two, and upload another 
patch.  I'll also fix the nested #ifs.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-21 12:41

Message:
Logged In: YES 
user_id=21627

How does this compare to #579433, in your opinion?

I like that this patch uses autoconf for ptmx usage, but I 
wonder whether the various pushes are necessary in the 
other patch.

Please use #elif instead of nested #ifs where possible.

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

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


From noreply@sourceforge.net  Wed Jan  1 14:54:23 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 06:54:23 -0800
Subject: [Patches] [ python-Patches-656590 ] /dev/ptmx support for ptys (cygwin)
Message-ID: <E18TkGF-0000qJ-00@sc8-sf-web1.sourceforge.net>

Patches item #656590, was opened at 2002-12-19 20:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=656590&group_id=5470

Category: Modules
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Paul Swartz (z3p)
Assigned to: Neal Norwitz (nnorwitz)
Summary: /dev/ptmx support for ptys (cygwin)

Initial Comment:
On Cygwin (and I believe Solaris, but I'm not sure), ptys 
are allocated using /dev/ptmx.  This patch checks 
for /dev/ptmx, and if it exists and openpty and _getpty 
don't, it will open ptys using /dev/ptmx.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-01 09:54

Message:
Logged In: YES 
user_id=33168

Excellent Martin!  With your last set of changes, the hang
is gone on HPUX.  I'm reverting the change to test_pty which
commented out the call to isatty().

test_pty.py 1.17

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-01 04:53

Message:
Logged In: YES 
user_id=21627

I have now changed slave_open to push ptem and ldterm, and
autodetect stropts.h (which is the POSIX name of that
header), in

configure 1.372
configure.in 1.383
pyconfig.h.in 1.68
pty.py 1.13
NEWS 1.587
fcntlmodule.c 2.37
posixmodule.c 2.280


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 17:36

Message:
Logged In: YES 
user_id=33168

ttyname is similar: /dev/pts/6

I verified that I_PUSH is also (ord('S')<<8)|2

I tried doing this:

  import pty
  master_fd, slave_name = pty.master_open()
  slave_fd = pty.slave_open(slave_name)
  fcntl.ioctl.(slave_fd, ((ord('S')<<8)|2), "ptem")


But after the ioctl, I got:
  IOError: [Errno 22] Invalid argument


Is this what you were doing?  Does this work for you?  If
it's easier, we can do this through email too.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 16:07

Message:
Logged In: YES 
user_id=21627

What is the ttyname returned from master_open?

On Solaris, I noticed that the isatty call also fails, and
the device name is /dev/pts/<n>, where n in a number.
pts(7D) reveals that merely opening that device is not
sufficient: you also need to push "ptem" and "ldterm". In
fact, pushing ptem alone is sufficient to make isatty succeed.

Could you try  whether pushing those drivers in slave_open
changes the behaviour? Exposing I_PUSH isn't strictly
necessary for this; I_PUSH = ((ord('S')<<8)|2) worked fine
for me (after reading stropts.h).

If that works, I think we should expose the entire family of
I_ constants in fcntl, and try pushing the drivers in
slave_open; if I_PUSH is not present or pusing a driver
fails, we return the "raw" file descriptor.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 15:26

Message:
Logged In: YES 
user_id=33168

Here's what I've found so far.

The test does: pty.master_open() which does an openpty(),
but closes the slave_fd.  The test then reopens the slave by
doing pty.slave_open().  Calling isatty() on this fd causes
HPUX to hang.  Note:  master_open() and slave_open have been
deprecated since 2.0, if I'm reading CVS logs properly (1.4
of pty.py).  Neither is documented.

I have no idea specifically why the hang occurs.  There's no
strace/truss installed for tracing syscalls.  From gdb,
here's the stack trace:

#0  0x77f9e548 in _ioctl_sys () from /usr/lib/libc.2
#1  0x77f282f4 in isatty () from /usr/lib/libc.2
#2  0x14d484 in posix_isatty (self=0x0, args=0x4004fbd0)
    at ./Modules/posixmodule.c:5414


Using openpty() works just fine.  I'm not sure how to
proceed.  One option is to remove master_open() and
slave_open().  I don't know if this is good or not.  We can
certainly skip the isatty() part of the test on HPUX.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 13:21

Message:
Logged In: YES 
user_id=33168

Martin, I agree with everything you said.  I'm commenting
out the test for now.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 13:14

Message:
Logged In: YES 
user_id=21627

Ok, I have removed the test for the master from test_openpty 
1.8. As for the test hanging: can you perform strace/truss on 
that machine to see what it is doing? On Solaris, isatty 
translates to ioctl(fd, TCGETA, struct termio); a terminal is a 
file that supports this ioctl.

If we need a quick work-around for 2.3a1, I suggest to skip 
that test temporarily for hpux. I would not like to backout this 
change, as the code appears to be basically correct.

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

Comment By: Paul Swartz (z3p)
Date: 2002-12-31 13:10

Message:
Logged In: YES 
user_id=123843

The code comes from the OpenSSH pty handling code.  I 
can't see why isatty would be hanging, but I don't think 
O_NONBLOCK can hurt.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 12:57

Message:
Logged In: YES 
user_id=33168

The code seems to work, I can believe it's the test.  I
don't understand why isatty(slave_fd) hangs though.  Paul's
code is the same as the HPUX man page, with one exception
the man page doesn't use O_NOCTTY.  However, removing this
flag makes no difference.

Should we use O_NONBLOCK?  I haven't tried it.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 12:52

Message:
Logged In: YES 
user_id=21627

I get the same on Solaris. Could it be that the test is
broken? Why should the master end be itself a terminal?

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

Comment By: Paul Swartz (z3p)
Date: 2002-12-31 12:48

Message:
Logged In: YES 
user_id=123843

The only thing that I can think of to try is on the slave end:

fd = os.open('/dev/tty', os.O_RDWR|os.O_NOCTTY)
if fd:
    fnctl.ioctl(fd, tty.TIOCNOTTY, '')
    close(fd)
fcntl.ioctl(slavefd, tty.TIOCSCTTY, '')

That should disconnect the slave from it's old controlling TTY 
and reconnect it to the new TTY.  (I'm not sure if it will come 
through, lines 3 and 4 are indented.)  Past this, I have no 
idea, as it works for me.

As for HPUX also needing sys/stropts.h, maybe adding a 
check for that file is a better idea then checking for sun/hpux.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 12:18

Message:
Logged In: YES 
user_id=33168

Paul, I had to modify the patch a bit to get posixmodule.c
to compile on HPUX11.  HPUX also needs sys/stropts.h for
I_PUSH and the macro is __hpux, not _hpux.

However, after making these changes, test_openpty fails: 
'Master-end of pty is not a terminal' and test_pty hangs
when doing:  if not os.isatty(slave_fd)

Any ideas?

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 07:57

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

configure 1.371
configure.in 1.382
pyconfig.h.in 1.67
ACKS 1.221
NEWS 1.581
posixmodule.c 2.277


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

Comment By: Paul Swartz (z3p)
Date: 2002-12-27 14:13

Message:
Logged In: YES 
user_id=123843

Fixed to use __CYGWIN__.  I don't think doing forkpty in the 
same way is the right idea, given that pty.fork() does the 
same thing and is the "right" way to fork with ptys.  The 
openpty change is necessary because there is no way 
duplicate it from pure-python, whereas forkpty can be 
duplicated with openpty/fork.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-27 05:25

Message:
Logged In: YES 
user_id=21627

It is common in Python to check for cygwin by checking
whether __CYGWIN__ is defined, so there is no need to invent
another mechanism.

Also, could you work out patches for forkpty as well?

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

Comment By: Paul Swartz (z3p)
Date: 2002-12-21 13:23

Message:
Logged In: YES 
user_id=123843

I reconciled the openpty parts of the two patches, and have 
attached a new patch.  The only thing I wonder about is if 
there is a better way to check for Cygwin in posixmodule.  
Adding an extra define seems like the wrong way.

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

Comment By: Paul Swartz (z3p)
Date: 2002-12-21 11:49

Message:
Logged In: YES 
user_id=123843

I took a look at the other patch, and back at the OpenSSH 
pty code (where I got the idea).  The pushes are in an '#ifndef 
CYGWIN' in OpenSSH, and the ioctl for ttcompant is in 
an '#ifndef _hpux'.  Not changing the SIGCHLD handler didn't 
break the cygwin code, but I doubt adding that would break 
things.  I'll work on combining the two, and upload another 
patch.  I'll also fix the nested #ifs.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-21 06:41

Message:
Logged In: YES 
user_id=21627

How does this compare to #579433, in your opinion?

I like that this patch uses autoconf for ptmx usage, but I 
wonder whether the various pushes are necessary in the 
other patch.

Please use #elif instead of nested #ifs where possible.

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

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


From noreply@sourceforge.net  Wed Jan  1 16:56:04 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 08:56:04 -0800
Subject: [Patches] [ python-Patches-660618 ] math.loggamma(z)
Message-ID: <E18TmA0-00018L-00@sc8-sf-web4.sourceforge.net>

Patches item #660618, was opened at 2003-01-01 03:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660618&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: math.loggamma(z)

Initial Comment:
Add a function to compute ln(gamma(z)).  It's fast 
and easy to compute but is a major PITA when you 
need it and don't have it available.

It is useful by itself, for factorials, binomial 
coefficients, combinatorics, and for computing the 
beta function.

I'm not for growing the mathmodule by much, but 
this and an incomplete gamma are a fine pair of 
basic building blocks and belong in the tool chest.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-01-01 11:56

Message:
Logged In: YES 
user_id=31435

No numeric functions are "fast and easy" to do in a portable 
and robust way.  The second lngamme function here:

http://lib.stat.cmu.edu/apstat/245

claims better accuracy with fewer terms, and because that 
website is well-known in the stats world, is more 
trustworthy than a random site with many copyright claims 
and bizarre formatting <wink>.

That said, I'm at best -0 on adding functions to the math 
module that require custom code and can't even be 
explained to the vast bulk of Python's users.  (Yes, I know 
lngamma is a basic building block -- for the relatively small 
collection of people who play with that kind of block.).

In contrast, an "advanced functions"/"special functions" 
module would be great.

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

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


From noreply@sourceforge.net  Wed Jan  1 19:52:44 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 11:52:44 -0800
Subject: [Patches] [ python-Patches-515003 ] Added HTTP{,S}ProxyConnection
Message-ID: <E18Touy-0005qN-00@sc8-sf-web4.sourceforge.net>

Patches item #515003, was opened at 2002-02-08 16:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Mihai Ibanescu (misa)
Assigned to: Jeremy Hylton (jhylton)
Summary: Added HTTP{,S}ProxyConnection

Initial Comment:
This patch adds HTTP*Connection classes for proxy
connections. Authenticated proxies are also supported.

One can argue urllib2 already implements this. It does
not do HTTPS tunneling through proxies, and this is
intended to be lower-level than urllib2.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-01 14:52

Message:
Logged In: YES 
user_id=33168

Isaac, can you send me the patch?  nnorwitz@users.sf.net
should work

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

Comment By: Isaac Salsberg (isalsberg)
Date: 2002-12-19 20:54

Message:
Logged In: YES 
user_id=663978

Neal, taht's right, I can not attach a file. 
I don't think is a good idea to close this patch, because
Misa is still working on it to fix some  persistence issue.

The version I created is based on the current Misa's 
version, so it has the same persistence problem. It just
was adapted to be used with Python 2.2.2. So we need to
wait for Misa's final version. 

I sent the patch to Misa, in case he wants to atach it here 
meanwhile the last version arrives. Except for persistence, 
It is working for me in a production environment. 

Anyway, If You need the patch I can send it. Just give me 
an email address. 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-14 21:09

Message:
Logged In: YES 
user_id=33168

Isaac, I don't believe SF allows you to attach a file to
someone else's patch.  Please submit a new patch.  In the
comments for the new patch refer to this patch and indicate
if it supercedes this patch (ie, should this patch be
closed).  Also, it would be nice if you can add a comment to
this patch mentioning the new patch number.  Thanks!

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

Comment By: Isaac Salsberg (isalsberg)
Date: 2002-12-14 19:52

Message:
Logged In: YES 
user_id=663978

To make this patch work with the "buggy"  IIS using python 
2.2 or 2.2.1 with https, You need to install also these 2 
patches:

551273 (fix httplib bug with 100 Continue) and
500311 (work around for buggy https servers)

Python 2.2.2 by the other hand, has already incorparated 
those two patches, so You only need to add the HTTP{S} 
(515003) proxy patch. But since httplib has changed,  Misa's 
diff file will fail.

I have created a diff file that works with python 2.2.2, which 
also includes a new example that works using a certificate  
file in PEM format. I wanted to attach the file, however
I could not find out how :-(

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

Comment By: Mihai Ibanescu (misa)
Date: 2002-11-05 15:56

Message:
Logged In: YES 
user_id=205865

I am having problems with proxying and keepalive
connections. Setting to a lower priority until I figure out
the documentation.

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

Comment By: Mihai Ibanescu (misa)
Date: 2002-10-07 17:20

Message:
Logged In: YES 
user_id=205865

Boy, two months. Yes, I'll go back to working on the patch.
Sorry for the delay.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-07 17:17

Message:
Logged In: YES 
user_id=21627

misa, is a patch forthcoming?

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

Comment By: Mihai Ibanescu (misa)
Date: 2002-07-15 17:37

Message:
Logged In: YES 
user_id=205865

- I agree about the comments. I'll make them reasonable.
- one underscore is fine
- I intended to have a patch that works with python 1.5, but
then again the module itself doesn't run with 1.5 anyway, so
good point.
- When you make a connection to a server through a proxy,
you have to connect to the proxy, but everything else should
be the same, i.e. the Host: field has to refer to the server
and so on. I wanted to reuse the code from _set_hostport,
which saves the host and port in self.host, self.port. Had
to do it twice, once for the proxy hostname, once for the
server's. _set_hostport takes care of the default port and
of the "hostname:port" syntax, which is convenient.

I'll put together a patched patch and upload it.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-07-15 17:21

Message:
Logged In: YES 
user_id=31392

The proposed classes seem useful enough, but I would like to
make several suggestions for the implementation.

- There are too many comments.  Comments should only be
added when 
   the intent of the code needs to be explained.  We
definitely don't need
   one comment for each line of code.  The comment in the
HTTPS proxy
   putrequest() is an example of a helpful comment.

- Just use a single underscore for private variables.

- Please use string methods instead of the string module.

- I don't understand the logic of switching the host/port
back and forth.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-07-15 16:52

Message:
Logged In: YES 
user_id=31392

I'll take a look.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-07-12 11:46

Message:
Logged In: YES 
user_id=6380

Assigning to Jeremy in the hope that he can provide a review.

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

Comment By: Mihai Ibanescu (misa)
Date: 2002-06-23 23:03

Message:
Logged In: YES 
user_id=205865

The newer patch is generated against the latest CVS tree,
and it provides additional documentation.

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

Comment By: Mihai Ibanescu (misa)
Date: 2002-06-11 14:47

Message:
Logged In: YES 
user_id=205865

Sorry, been caught with a zillion of other things to do.
I'll try to reorganize it somehow and ask for opinions.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-11 14:42

Message:
Logged In: YES 
user_id=31392

misa-- any progress on this patch?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 18:12

Message:
Logged In: YES 
user_id=6380

OK, thanks; I'll wait!

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

Comment By: Mihai Ibanescu (misa)
Date: 2002-03-01 17:58

Message:
Logged In: YES 
user_id=205865

I will add documentation and show the intended usage.
urllib* doesn't deal with proxying over SSL (using CONNECT
instead of GET/POST). urllib* also use the compatibility
classes, HTTP/HTTPS, instead of HTTPConnection (this is not
an argument by itself).
Thanks for the suggestion.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:40

Message:
Logged In: YES 
user_id=6380

This patch fails to seduce me. There's no explanation why
this would be useful, or how it should be used, and no
documentation, and a hint that urllib2 already does this.

Maybe you can get someone who's known on python-dev to
champion it, if you think it's useful?

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

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


From noreply@sourceforge.net  Wed Jan  1 20:09:22 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 12:09:22 -0800
Subject: [Patches] [ python-Patches-640843 ] Fix breakage caused when user sets OPT
Message-ID: <E18TpB4-0005b2-00@sc8-sf-web3.sourceforge.net>

Patches item #640843, was opened at 2002-11-19 12:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=640843&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: Fix breakage caused when user sets OPT

Initial Comment:
The attached patch tries to fix the problems caused by 
overloading OPT in ./configure.  The problem is that OPT contains 
two different kinds of information, optimization/debug flags and 
other flags which are required to get code to simply compile.  If 
you override OPT when running configure or make, you may wipe 
out compiler flags necessary to simply compile the interpreter.

This needs some testing.

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

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-01 14:09

Message:
Logged In: YES 
user_id=44345

Checked in as:

    Makefile.pre.in 1.108
    configure 1.373
    configure.in 1.384
    setup.py 1.132
    Misc/NEWS 1.588


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

Comment By: Skip Montanaro (montanaro)
Date: 2002-12-31 11:02

Message:
Logged In: YES 
user_id=44345

Latest version.  It's a monster patch only because I included the diffs for configure.  Other than the addition of a blurb to Misc/NEWS I'm not sure there's any difference from my November patch.  There are a couple unrelated lines in setup.py to search the fink directories on Darwin.


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

Comment By: Skip Montanaro (montanaro)
Date: 2002-11-19 20:27

Message:
Logged In: YES 
user_id=44345

dang opera seems to be having file upload problems.  Guess it's back to 
Exploder...  You should be able to trim the binary garbage from the start 
and end of the file and get a clean patch.  The first word should be 
"Index" and the last line should end in "@LDLAST@"

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

Comment By: Skip Montanaro (montanaro)
Date: 2002-11-19 20:25

Message:
Logged In: YES 
user_id=44345

uploading new context diff - forgot to rerun autoconf after the
last change to 
configure.in... :-(

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

Comment By: Skip Montanaro (montanaro)
Date: 2002-11-19 20:24

Message:
Logged In: YES 
user_id=44345

uploading new context diff - forgot to rerun autoconf after the
last change to 
configure.in... :-(

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

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


From noreply@sourceforge.net  Wed Jan  1 20:09:40 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 12:09:40 -0800
Subject: [Patches] [ python-Patches-590513 ] Add popen2 like functionality to pty.py.
Message-ID: <E18TpBM-0006UE-00@sc8-sf-web4.sourceforge.net>

Patches item #590513, was opened at 2002-08-03 10:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590513&group_id=5470

Category: Library (Lib)
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rasjid Wilcox (rasjidw)
Assigned to: Thomas Wouters (twouters)
Summary: Add popen2 like functionality to pty.py.

Initial Comment:
This patch adds a popen2 like function to pty.py.

Due to use of os.execlp in pty.spawn, it is not quite
the same, as all the arguments (including the command
to be run) must be passed as a tupple.

It is only a first draft, and may need some more work,
which I am willing to do if some direction is indicated.

Tested on Python2.2, under RedHat Linux 7.3.

Rasjid.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-01 15:09

Message:
Logged In: YES 
user_id=33168

What is the status of this patch?  Rasjid do still plan to
produce an updated patch.  Note: 2.3 alpha 1 was released
yesterday.

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

Comment By: Rasjid Wilcox (rasjidw)
Date: 2002-09-10 07:38

Message:
Logged In: YES 
user_id=39640

Thanks for the comments Thomas.
a) I have not done docs or testcase yet.  I wanted to be
clear about the direction first.  I will submit with my next
version.
b) No particular reason for threads, just more intuitive to
me.  On due reflection, os.fork is better.  I shall drop the
use of threads.
c) I shall keep backward compatibility.  Perhaps
'returning_spawn' for the new version.
With luck, next version in a couple of weeks.

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

Comment By: Thomas Wouters (twouters)
Date: 2002-09-09 09:57

Message:
Logged In: YES 
user_id=34209

I have several comments, but I'm not sure if they've been
adressed in other forums or not. Guido mentions
documentation, but the patches attached don't seem to
contain them; are they seperate ? I also don't see a testcase.

 - Why threads ? A seperate non-thread version, with a third
process to handle the data trafficking, and falling back to
that when threads are not available would be nice.

 - I concur the new behaviour is much more useful. However,
I'm a stickler for backward compatibility, so I advice
against renaming the old spawn :)

 - I don't like 'th_spawn'. 'spawn_thread' or
'threaded_spawn' or some such sound better to me (but see
above about threads.)

 - Some minor whitespace issues (the line-wrap on line 150
is not necessary, line 179 is too long, and the backslashes
on lines 190 and 205 are not necessary.) A comment
describing why the tty.setraw() is done would also be nice.


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

Comment By: Rasjid Wilcox (rasjidw)
Date: 2002-08-29 23:54

Message:
Logged In: YES 
user_id=39640

Okay.  My final version (I promise!).  The code has been
reorganised a little so that:
a) it is cleaner to read
b) the popen2 function now returns the pid of the child process

Rasjid.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-20 14:33

Message:
Logged In: YES 
user_id=6380

Assigning this to Thomas Wouters according to his wishes.

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

Comment By: Thomas Wouters (twouters)
Date: 2002-08-16 09:47

Message:
Logged In: YES 
user_id=34209

The pty module actually works on all platforms that provide
openpty(). I know at least BSDI and FreeBSD do, in addition
to Linux, and I suspect OpenBSD and NetBSD as well, and
possibly other BSD-derived systems. Still, it is very
unlikely to work on non-POSIX-ish systems, so /bin/sh is a
safe bet.

I can take a look at the patch, and test it on a variety of
machines, but not before I leave on a two-week vacation,
this sunday :) I have plenty of time to look at it when I'm
back though, in the first week of September. Feel free to
assign the patch to me, as a reminder.


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

Comment By: Rasjid Wilcox (rasjidw)
Date: 2002-08-16 08:39

Message:
Logged In: YES 
user_id=39640

Okay.  This is essentially my final version, subject to an
issue around the naming of a couple of the modules functions.

My issue is that the pty.spawn funciton does not return.  My
new one 'th_spawn' function does.  I believe quite strongly
that to be consistent with the rest of python, 'th_spawn'
should be renamed 'spawn', and the current spawn function
should be renamed something like '_master' since it takes
the place of the pty master.

The issue of course is backward compatibility.  However, I
believe this to be relatively minor for two reasons.
1.  I think very few (if any) people are using it, since it was
a) largely undocumented,
b) didn't always work
c) wasn't particularly useful, since it only allowed control
from an existing pty (so what was the point?)
2.  If anyone is using it, they would _almost_ certainly be
starting it on a new thread, so all that would happen if the
functions were renamed would be that an extra (redundant)
sub-thread is created.

I have posted to comp.lang.python to see what other pty.py
users think.  Subject to the response here and there, I may
post to python-dev in due course.

Rasjid.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-05 11:20

Message:
Logged In: YES 
user_id=6380

I mostly concur with Martin von Loewis's comments, though
I'm not sure this is big enough for a PEP. I think that
you're right in answering (yes, no, yes) but I have no
information (portability of this module is already limited
to IRIX and Linux, according to the docs).

The docs use the word "baffle" -- I wonder if you could
substitute something else or generally clarify that
sentence; it's not very clear from the docs what spawn()
does (nor what fork() does, to tell the truth -- all these
could really use some examples).

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-05 07:44

Message:
Logged In: YES 
user_id=21627

I'm not a regular pty user. Please ask those questions in
comp.lang.python, and python-dev. You can also ask previous
authors to pty for comments.

Uncertainty in such areas might be a hint that a library PEP
is need, to justify the rationale for all the details.

There is no need to hurry - Python 2.3 is still months away.

That said, I do think that this functionality is desirable,
so I'd encourage you to complete this task.

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

Comment By: Rasjid Wilcox (rasjidw)
Date: 2002-08-05 07:34

Message:
Logged In: YES 
user_id=39640

Before I do docs etc, I have a few questions:

1.  I could make it more popen2 like by changing the args to
def popen2(cmd, ....)  and adding argv=('/bin/sh','-c',cmd)

Is this a better idea?  Does it reduce portability?  Is it
safe to assume that all posix systems have /bin/sh? (My
guess is yes, no and yes.)

2.  Should the threading done in the pty.popen2 function be
moved to a separate function, to allow more direct access to
spawn.  (The current spawn function does not return until
the child exits or the parent closes the pipe).

3.  Should I worry about how keyboard interrupts are
handled?  In some cases an uncontrolled process may be left
hanging around.  Or is it the job of the calling process to
deal with that?

Lastly, I am away for a week from Wednesday, so I won't be
able to do much until I get back, but I will try and finish
this off then.

Cheers,

Rasjid.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 04:56

Message:
Logged In: YES 
user_id=21627

Can you please write documentation and a test case?

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

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


From noreply@sourceforge.net  Wed Jan  1 21:53:18 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 13:53:18 -0800
Subject: [Patches] [ python-Patches-660618 ] math.loggamma(z)
Message-ID: <E18Tqne-0001S0-00@sc8-sf-web4.sourceforge.net>

Patches item #660618, was opened at 2003-01-01 03:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660618&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Nobody/Anonymous (nobody)
Summary: math.loggamma(z)

Initial Comment:
Add a function to compute ln(gamma(z)).  It's fast 
and easy to compute but is a major PITA when you 
need it and don't have it available.

It is useful by itself, for factorials, binomial 
coefficients, combinatorics, and for computing the 
beta function.

I'm not for growing the mathmodule by much, but 
this and an incomplete gamma are a fine pair of 
basic building blocks and belong in the tool chest.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-01 16:53

Message:
Logged In: YES 
user_id=80475

Thanks for the link.  Revised the patch to use the 
coefficients published there.  Also, incorporated the 
knowledge of how to use it in the docs.

While another module has its merits, I greatly prefer 
putting this function in the mathmodule because that is 
the first place someone would look for it.  It is not out of 
place with tanh() or the other double to double functions. 

The users of the mathmodule are more likely to be in 
educational or scientific settings rather than being 
everyday python users.  And the docs make it clear how to 
use the function.



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

Comment By: Tim Peters (tim_one)
Date: 2003-01-01 11:56

Message:
Logged In: YES 
user_id=31435

No numeric functions are "fast and easy" to do in a portable 
and robust way.  The second lngamme function here:

http://lib.stat.cmu.edu/apstat/245

claims better accuracy with fewer terms, and because that 
website is well-known in the stats world, is more 
trustworthy than a random site with many copyright claims 
and bizarre formatting <wink>.

That said, I'm at best -0 on adding functions to the math 
module that require custom code and can't even be 
explained to the vast bulk of Python's users.  (Yes, I know 
lngamma is a basic building block -- for the relatively small 
collection of people who play with that kind of block.).

In contrast, an "advanced functions"/"special functions" 
module would be great.

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

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


From noreply@sourceforge.net  Wed Jan  1 22:48:27 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 14:48:27 -0800
Subject: [Patches] [ python-Patches-642236 ] optparse LaTeX docs (bug #638703)
Message-ID: <E18Trf1-0008RX-00@sc8-sf-web2.sourceforge.net>

Patches item #642236, was opened at 2002-11-22 06:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=642236&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse LaTeX docs (bug #638703)

Initial Comment:
As said in my comment on bug #638703, I've made 
some LaTeX documentation based on the text files from 
the standalone Optik package. Contrary to my comment 
there, I haven't added reference documentation based on 
pydoc.help(optparse). I'm not convinced this would add 
any value to the documentation.

An archive is attached with:

- liboptparse.tex
- patch for lib.tex
- patch for Makefile.deps

And three example files, used in liboptparse.tex (with 
\verbatiminput)
- required_1.py
- required_2.py
- caseless.py

The diffs are based on 14/11 CVS, because my 
workstation isn't on the internet. I have to mirror Python 
CVS using a CD-RW from another computer.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-01 17:48

Message:
Logged In: YES 
user_id=33168

Updated attachment to have everything in one patch file.

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

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


From noreply@sourceforge.net  Thu Jan  2 01:52:34 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 17:52:34 -0800
Subject: [Patches] [ python-Patches-660559 ] Use METH_O and METH_NOARGS where possible
Message-ID: <E18TuXC-0007rc-00@sc8-sf-web4.sourceforge.net>

Patches item #660559, was opened at 2002-12-31 18:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660559&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Walter Dörwald (doerwalter)
Summary: Use METH_O and METH_NOARGS where possible

Initial Comment:
Speed-up calls and tighten code in operator.c 
arraymodule.c, and cStringIO.c by using METH_O, 
METH_NOARGS and PyArg_UnpackTuple.

Didn't touch other modules that I wasn't familiar with 
or that didn't look like they would benefit from the 
speedup.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-01-01 20:52

Message:
Logged In: YES 
user_id=31435

Note that a METH_NOARGS function is still called, at the C 
level, with two arguments.  The second argument is always 
NULL, and sooner or later some platform C is going to blow 
up when that's passed to a function declared to take only 
one argument ("the usual" cast to PyCFunction shuts up the 
compile-time warnings).

It's not your job to fix that everywhere, but new uses of 
METH_NOARGS shouldn't add to this problem.  Declaring a 
second PyObject * argument with a name like "unused" 
or "dummy" would be fine.

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

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


From noreply@sourceforge.net  Thu Jan  2 02:27:03 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 18:27:03 -0800
Subject: [Patches] [ python-Patches-660559 ] Use METH_O and METH_NOARGS where possible
Message-ID: <E18Tv4Z-0000Xm-00@sc8-sf-web4.sourceforge.net>

Patches item #660559, was opened at 2002-12-31 18:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660559&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Walter Dörwald (doerwalter)
Summary: Use METH_O and METH_NOARGS where possible

Initial Comment:
Speed-up calls and tighten code in operator.c 
arraymodule.c, and cStringIO.c by using METH_O, 
METH_NOARGS and PyArg_UnpackTuple.

Didn't touch other modules that I wasn't familiar with 
or that didn't look like they would benefit from the 
speedup.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-01 21:27

Message:
Logged In: YES 
user_id=80475

Fixed.  Revised patch attached.

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

Comment By: Tim Peters (tim_one)
Date: 2003-01-01 20:52

Message:
Logged In: YES 
user_id=31435

Note that a METH_NOARGS function is still called, at the C 
level, with two arguments.  The second argument is always 
NULL, and sooner or later some platform C is going to blow 
up when that's passed to a function declared to take only 
one argument ("the usual" cast to PyCFunction shuts up the 
compile-time warnings).

It's not your job to fix that everywhere, but new uses of 
METH_NOARGS shouldn't add to this problem.  Declaring a 
second PyObject * argument with a name like "unused" 
or "dummy" would be fine.

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

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


From noreply@sourceforge.net  Thu Jan  2 03:09:13 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 19:09:13 -0800
Subject: [Patches] [ python-Patches-558547 ] SocketServer: don't flush closed wfile
Message-ID: <E18TvjN-0001LF-00@sc8-sf-web3.sourceforge.net>

Patches item #558547, was opened at 2002-05-21 16:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558547&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: SocketServer: don't flush closed wfile

Initial Comment:
I've found the following patch (well, ok, subclassed,
but the patch is the same) makes SocketServer more 
robust. If wfile is already closed (prior to the 
finish() method being called), don't try to flush()
it. 



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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-01-02 14:09

Message:
Logged In: YES 
user_id=29957

committed as SocketServer.py, revision 1.35.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-04 21:19

Message:
Logged In: YES 
user_id=21627

I think the patch is fine. Please apply it.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-06-06 11:25

Message:
Logged In: YES 
user_id=29957

I'm not _entirely_ sure why it happens that finish() gets called
twice - I suspect some form of race condition. Since many/most
other similar functions in the python library silently ignore a 
close()-type operation (e.g. file.close(); file.close()). As
far as
the 'closed' attribute, well, yes, someone could subclass 
StreamRequestHandler.setup, and leave
StreamRequestHandler.finish
as-is. But then, it's only got two methods, so this is
highly unlikely.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-06-02 22:44

Message:
Logged In: YES 
user_id=21627

Can you explain how this problem can ever occur? I.e. why
would there be two calls to finish?

Also, is there a guarantee that every thing returned by
makefile has a .closed attribute?

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-21 16:25

Message:
Logged In: YES 
user_id=29957

mm. i typ reel gud sometimes.

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

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


From noreply@sourceforge.net  Thu Jan  2 03:30:47 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Jan 2003 19:30:47 -0800
Subject: [Patches] [ python-Patches-660618 ] math.loggamma(z)
Message-ID: <E18Tw4F-0001r7-00@sc8-sf-web3.sourceforge.net>

Patches item #660618, was opened at 2003-01-01 03:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660618&group_id=5470

Category: Modules
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: math.loggamma(z)

Initial Comment:
Add a function to compute ln(gamma(z)).  It's fast 
and easy to compute but is a major PITA when you 
need it and don't have it available.

It is useful by itself, for factorials, binomial 
coefficients, combinatorics, and for computing the 
beta function.

I'm not for growing the mathmodule by much, but 
this and an incomplete gamma are a fine pair of 
basic building blocks and belong in the tool chest.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-01 22:30

Message:
Logged In: YES 
user_id=80475

Withdrawing the patch.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-01 16:53

Message:
Logged In: YES 
user_id=80475

Thanks for the link.  Revised the patch to use the 
coefficients published there.  Also, incorporated the 
knowledge of how to use it in the docs.

While another module has its merits, I greatly prefer 
putting this function in the mathmodule because that is 
the first place someone would look for it.  It is not out of 
place with tanh() or the other double to double functions. 

The users of the mathmodule are more likely to be in 
educational or scientific settings rather than being 
everyday python users.  And the docs make it clear how to 
use the function.



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

Comment By: Tim Peters (tim_one)
Date: 2003-01-01 11:56

Message:
Logged In: YES 
user_id=31435

No numeric functions are "fast and easy" to do in a portable 
and robust way.  The second lngamme function here:

http://lib.stat.cmu.edu/apstat/245

claims better accuracy with fewer terms, and because that 
website is well-known in the stats world, is more 
trustworthy than a random site with many copyright claims 
and bizarre formatting <wink>.

That said, I'm at best -0 on adding functions to the math 
module that require custom code and can't even be 
explained to the vast bulk of Python's users.  (Yes, I know 
lngamma is a basic building block -- for the relatively small 
collection of people who play with that kind of block.).

In contrast, an "advanced functions"/"special functions" 
module would be great.

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

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


From noreply@sourceforge.net  Thu Jan  2 10:22:51 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 02:22:51 -0800
Subject: [Patches] [ python-Patches-590513 ] Add popen2 like functionality to pty.py.
Message-ID: <E18U2V1-00023N-00@sc8-sf-web2.sourceforge.net>

Patches item #590513, was opened at 2002-08-04 00:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590513&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rasjid Wilcox (rasjidw)
Assigned to: Thomas Wouters (twouters)
Summary: Add popen2 like functionality to pty.py.

Initial Comment:
This patch adds a popen2 like function to pty.py.

Due to use of os.execlp in pty.spawn, it is not quite
the same, as all the arguments (including the command
to be run) must be passed as a tupple.

It is only a first draft, and may need some more work,
which I am willing to do if some direction is indicated.

Tested on Python2.2, under RedHat Linux 7.3.

Rasjid.


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

>Comment By: Rasjid Wilcox (rasjidw)
Date: 2003-01-02 21:22

Message:
Logged In: YES 
user_id=39640

I do plan to do so, but some of Thomas' comments required         
some thought, and in the meantime other priorities came up.   
Also, writing docs and a testcase will take some time (and  
thought) and seem to be the most requrested aspect.   
Realistically, I would expect to get to it within the next month or        
two.  Unfortunately, I can't really promise much more than that. 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-02 07:09

Message:
Logged In: YES 
user_id=33168

What is the status of this patch?  Rasjid do still plan to
produce an updated patch.  Note: 2.3 alpha 1 was released
yesterday.

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

Comment By: Rasjid Wilcox (rasjidw)
Date: 2002-09-10 21:38

Message:
Logged In: YES 
user_id=39640

Thanks for the comments Thomas.
a) I have not done docs or testcase yet.  I wanted to be
clear about the direction first.  I will submit with my next
version.
b) No particular reason for threads, just more intuitive to
me.  On due reflection, os.fork is better.  I shall drop the
use of threads.
c) I shall keep backward compatibility.  Perhaps
'returning_spawn' for the new version.
With luck, next version in a couple of weeks.

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

Comment By: Thomas Wouters (twouters)
Date: 2002-09-09 23:57

Message:
Logged In: YES 
user_id=34209

I have several comments, but I'm not sure if they've been
adressed in other forums or not. Guido mentions
documentation, but the patches attached don't seem to
contain them; are they seperate ? I also don't see a testcase.

 - Why threads ? A seperate non-thread version, with a third
process to handle the data trafficking, and falling back to
that when threads are not available would be nice.

 - I concur the new behaviour is much more useful. However,
I'm a stickler for backward compatibility, so I advice
against renaming the old spawn :)

 - I don't like 'th_spawn'. 'spawn_thread' or
'threaded_spawn' or some such sound better to me (but see
above about threads.)

 - Some minor whitespace issues (the line-wrap on line 150
is not necessary, line 179 is too long, and the backslashes
on lines 190 and 205 are not necessary.) A comment
describing why the tty.setraw() is done would also be nice.


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

Comment By: Rasjid Wilcox (rasjidw)
Date: 2002-08-30 13:54

Message:
Logged In: YES 
user_id=39640

Okay.  My final version (I promise!).  The code has been
reorganised a little so that:
a) it is cleaner to read
b) the popen2 function now returns the pid of the child process

Rasjid.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-21 04:33

Message:
Logged In: YES 
user_id=6380

Assigning this to Thomas Wouters according to his wishes.

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

Comment By: Thomas Wouters (twouters)
Date: 2002-08-16 23:47

Message:
Logged In: YES 
user_id=34209

The pty module actually works on all platforms that provide
openpty(). I know at least BSDI and FreeBSD do, in addition
to Linux, and I suspect OpenBSD and NetBSD as well, and
possibly other BSD-derived systems. Still, it is very
unlikely to work on non-POSIX-ish systems, so /bin/sh is a
safe bet.

I can take a look at the patch, and test it on a variety of
machines, but not before I leave on a two-week vacation,
this sunday :) I have plenty of time to look at it when I'm
back though, in the first week of September. Feel free to
assign the patch to me, as a reminder.


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

Comment By: Rasjid Wilcox (rasjidw)
Date: 2002-08-16 22:39

Message:
Logged In: YES 
user_id=39640

Okay.  This is essentially my final version, subject to an
issue around the naming of a couple of the modules functions.

My issue is that the pty.spawn funciton does not return.  My
new one 'th_spawn' function does.  I believe quite strongly
that to be consistent with the rest of python, 'th_spawn'
should be renamed 'spawn', and the current spawn function
should be renamed something like '_master' since it takes
the place of the pty master.

The issue of course is backward compatibility.  However, I
believe this to be relatively minor for two reasons.
1.  I think very few (if any) people are using it, since it was
a) largely undocumented,
b) didn't always work
c) wasn't particularly useful, since it only allowed control
from an existing pty (so what was the point?)
2.  If anyone is using it, they would _almost_ certainly be
starting it on a new thread, so all that would happen if the
functions were renamed would be that an extra (redundant)
sub-thread is created.

I have posted to comp.lang.python to see what other pty.py
users think.  Subject to the response here and there, I may
post to python-dev in due course.

Rasjid.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-06 01:20

Message:
Logged In: YES 
user_id=6380

I mostly concur with Martin von Loewis's comments, though
I'm not sure this is big enough for a PEP. I think that
you're right in answering (yes, no, yes) but I have no
information (portability of this module is already limited
to IRIX and Linux, according to the docs).

The docs use the word "baffle" -- I wonder if you could
substitute something else or generally clarify that
sentence; it's not very clear from the docs what spawn()
does (nor what fork() does, to tell the truth -- all these
could really use some examples).

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-05 21:44

Message:
Logged In: YES 
user_id=21627

I'm not a regular pty user. Please ask those questions in
comp.lang.python, and python-dev. You can also ask previous
authors to pty for comments.

Uncertainty in such areas might be a hint that a library PEP
is need, to justify the rationale for all the details.

There is no need to hurry - Python 2.3 is still months away.

That said, I do think that this functionality is desirable,
so I'd encourage you to complete this task.

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

Comment By: Rasjid Wilcox (rasjidw)
Date: 2002-08-05 21:34

Message:
Logged In: YES 
user_id=39640

Before I do docs etc, I have a few questions:

1.  I could make it more popen2 like by changing the args to
def popen2(cmd, ....)  and adding argv=('/bin/sh','-c',cmd)

Is this a better idea?  Does it reduce portability?  Is it
safe to assume that all posix systems have /bin/sh? (My
guess is yes, no and yes.)

2.  Should the threading done in the pty.popen2 function be
moved to a separate function, to allow more direct access to
spawn.  (The current spawn function does not return until
the child exits or the parent closes the pipe).

3.  Should I worry about how keyboard interrupts are
handled?  In some cases an uncontrolled process may be left
hanging around.  Or is it the job of the calling process to
deal with that?

Lastly, I am away for a week from Wednesday, so I won't be
able to do much until I get back, but I will try and finish
this off then.

Cheers,

Rasjid.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 18:56

Message:
Logged In: YES 
user_id=21627

Can you please write documentation and a test case?

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

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


From noreply@sourceforge.net  Thu Jan  2 14:28:39 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 06:28:39 -0800
Subject: [Patches] [ python-Patches-661092 ] list.sort cmpfunc default
Message-ID: <E18U6Kt-00056S-00@sc8-sf-web4.sourceforge.net>

Patches item #661092, was opened at 2003-01-02 08:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661092&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Tim Peters (tim_one)
Summary: list.sort cmpfunc default

Initial Comment:
It surprised me today when I saw a functional sort written like this:

def sort(sequence, cmpfunc=None):
    sorted = list(sequence)
    if cmpfunc is None:
        sorted.sort()
    else:
        sorted.sort(cmpfunc)
    return sorted

If [].sort() was written in Python its function signature would be declared as above (obviously the body would be different), and the above functional sort could be written as:

def sort(sequence, cmpfunc=None):
    sorted = list(sequence)
    sorted.sort(cmpfunc)
    return sorted

The attached patch supports calling [].sort() with an explicit argument of None.  (No doc change yet. If you approve, I will make that mod.)


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

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


From noreply@sourceforge.net  Thu Jan  2 16:19:44 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 08:19:44 -0800
Subject: [Patches] [ python-Patches-661092 ] list.sort cmpfunc default
Message-ID: <E18U84O-0006vn-00@sc8-sf-web1.sourceforge.net>

Patches item #661092, was opened at 2003-01-02 09:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661092&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Tim Peters (tim_one)
Summary: list.sort cmpfunc default

Initial Comment:
It surprised me today when I saw a functional sort written like this:

def sort(sequence, cmpfunc=None):
    sorted = list(sequence)
    if cmpfunc is None:
        sorted.sort()
    else:
        sorted.sort(cmpfunc)
    return sorted

If [].sort() was written in Python its function signature would be declared as above (obviously the body would be different), and the above functional sort could be written as:

def sort(sequence, cmpfunc=None):
    sorted = list(sequence)
    sorted.sort(cmpfunc)
    return sorted

The attached patch supports calling [].sort() with an explicit argument of None.  (No doc change yet. If you approve, I will make that mod.)


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-02 11:19

Message:
Logged In: YES 
user_id=33168

Skip, there's no file attached.  Unfortunately, SF doesn't
upload the file any more when submitting a new patch.

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

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


From noreply@sourceforge.net  Thu Jan  2 16:30:17 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 08:30:17 -0800
Subject: [Patches] [ python-Patches-661092 ] list.sort cmpfunc default
Message-ID: <E18U8Eb-0007Jz-00@sc8-sf-web1.sourceforge.net>

Patches item #661092, was opened at 2003-01-02 08:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661092&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Tim Peters (tim_one)
Summary: list.sort cmpfunc default

Initial Comment:
It surprised me today when I saw a functional sort written like this:

def sort(sequence, cmpfunc=None):
    sorted = list(sequence)
    if cmpfunc is None:
        sorted.sort()
    else:
        sorted.sort(cmpfunc)
    return sorted

If [].sort() was written in Python its function signature would be declared as above (obviously the body would be different), and the above functional sort could be written as:

def sort(sequence, cmpfunc=None):
    sorted = list(sequence)
    sorted.sort(cmpfunc)
    return sorted

The attached patch supports calling [].sort() with an explicit argument of None.  (No doc change yet. If you approve, I will make that mod.)


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

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-02 10:30

Message:
Logged In: YES 
user_id=44345

Thanks, Neal...  

*sigh*  I guess I didn't get the memo.  When I submitted the patch, I saw that the return screen was blank.  I checked a bit later to see if a patch had been created, but didn't think to check if the file was uploaded.  I'll check this time.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-02 10:19

Message:
Logged In: YES 
user_id=33168

Skip, there's no file attached.  Unfortunately, SF doesn't
upload the file any more when submitting a new patch.

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

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


From noreply@sourceforge.net  Thu Jan  2 16:40:20 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 08:40:20 -0800
Subject: [Patches] [ python-Patches-661092 ] list.sort cmpfunc default
Message-ID: <E18U8OK-0003nA-00@sc8-sf-web3.sourceforge.net>

Patches item #661092, was opened at 2003-01-02 09:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661092&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Tim Peters (tim_one)
Summary: list.sort cmpfunc default

Initial Comment:
It surprised me today when I saw a functional sort written like this:

def sort(sequence, cmpfunc=None):
    sorted = list(sequence)
    if cmpfunc is None:
        sorted.sort()
    else:
        sorted.sort(cmpfunc)
    return sorted

If [].sort() was written in Python its function signature would be declared as above (obviously the body would be different), and the above functional sort could be written as:

def sort(sequence, cmpfunc=None):
    sorted = list(sequence)
    sorted.sort(cmpfunc)
    return sorted

The attached patch supports calling [].sort() with an explicit argument of None.  (No doc change yet. If you approve, I will make that mod.)


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-02 11:40

Message:
Logged In: YES 
user_id=33168

The patch looks correct.  You should also add a test if Tim
accepts this.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-02 11:30

Message:
Logged In: YES 
user_id=44345

Thanks, Neal...  

*sigh*  I guess I didn't get the memo.  When I submitted the patch, I saw that the return screen was blank.  I checked a bit later to see if a patch had been created, but didn't think to check if the file was uploaded.  I'll check this time.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-02 11:19

Message:
Logged In: YES 
user_id=33168

Skip, there's no file attached.  Unfortunately, SF doesn't
upload the file any more when submitting a new patch.

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

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


From noreply@sourceforge.net  Thu Jan  2 17:13:44 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 09:13:44 -0800
Subject: [Patches] [ python-Patches-661092 ] list.sort cmpfunc default
Message-ID: <E18U8ue-00017i-00@sc8-sf-web1.sourceforge.net>

Patches item #661092, was opened at 2003-01-02 09:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661092&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: list.sort cmpfunc default

Initial Comment:
It surprised me today when I saw a functional sort written like this:

def sort(sequence, cmpfunc=None):
    sorted = list(sequence)
    if cmpfunc is None:
        sorted.sort()
    else:
        sorted.sort(cmpfunc)
    return sorted

If [].sort() was written in Python its function signature would be declared as above (obviously the body would be different), and the above functional sort could be written as:

def sort(sequence, cmpfunc=None):
    sorted = list(sequence)
    sorted.sort(cmpfunc)
    return sorted

The attached patch supports calling [].sort() with an explicit argument of None.  (No doc change yet. If you approve, I will make that mod.)


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

>Comment By: Tim Peters (tim_one)
Date: 2003-01-02 12:13

Message:
Logged In: YES 
user_id=31435

Looks good to me, Skip.  Accepted, & back to you.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-02 11:40

Message:
Logged In: YES 
user_id=33168

The patch looks correct.  You should also add a test if Tim
accepts this.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-02 11:30

Message:
Logged In: YES 
user_id=44345

Thanks, Neal...  

*sigh*  I guess I didn't get the memo.  When I submitted the patch, I saw that the return screen was blank.  I checked a bit later to see if a patch had been created, but didn't think to check if the file was uploaded.  I'll check this time.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-02 11:19

Message:
Logged In: YES 
user_id=33168

Skip, there's no file attached.  Unfortunately, SF doesn't
upload the file any more when submitting a new patch.

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

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


From noreply@sourceforge.net  Thu Jan  2 18:53:16 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 10:53:16 -0800
Subject: [Patches] [ python-Patches-660559 ] Use METH_O and METH_NOARGS where possible
Message-ID: <E18UASy-0004UW-00@sc8-sf-web2.sourceforge.net>

Patches item #660559, was opened at 2002-12-31 18:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660559&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Martin v. Löwis (loewis)
Summary: Use METH_O and METH_NOARGS where possible

Initial Comment:
Speed-up calls and tighten code in operator.c 
arraymodule.c, and cStringIO.c by using METH_O, 
METH_NOARGS and PyArg_UnpackTuple.

Didn't touch other modules that I wasn't familiar with 
or that didn't look like they would benefit from the 
speedup.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-01 21:27

Message:
Logged In: YES 
user_id=80475

Fixed.  Revised patch attached.

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

Comment By: Tim Peters (tim_one)
Date: 2003-01-01 20:52

Message:
Logged In: YES 
user_id=31435

Note that a METH_NOARGS function is still called, at the C 
level, with two arguments.  The second argument is always 
NULL, and sooner or later some platform C is going to blow 
up when that's passed to a function declared to take only 
one argument ("the usual" cast to PyCFunction shuts up the 
compile-time warnings).

It's not your job to fix that everywhere, but new uses of 
METH_NOARGS shouldn't add to this problem.  Declaring a 
second PyObject * argument with a name like "unused" 
or "dummy" would be fine.

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

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


From noreply@sourceforge.net  Thu Jan  2 20:06:09 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 12:06:09 -0800
Subject: [Patches] [ python-Patches-661281 ] reverse method for string objects.
Message-ID: <E18UBbV-0003kj-00@sc8-sf-web3.sourceforge.net>

Patches item #661281, was opened at 2003-01-02 21:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661281&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Wojtek Walczak (gminick)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse method for string objects.

Initial Comment:
Well, in python 2.3a1 you can reverse a string in dozens of ways, for example:
>>> a = 'string'
>>> a[::-1]
'gnirts'
>>> reduce(lambda x,y: y+x, a)
'gnirts'
>>> b = list(a)
>>> b.reverse()
>>> "".join(b)
'gnirts'
but there's no simple method as function reverse() in plenty of languages. That patch changes that situation by adding reverse method to Objects/stringobject.c
Tested on Linux 2.4.5 with Python2.3alpha1 with i586 platform.
Feel free to improve that or throw it away :)

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

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


From noreply@sourceforge.net  Thu Jan  2 20:53:54 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 12:53:54 -0800
Subject: [Patches] [ python-Patches-661092 ] list.sort cmpfunc default
Message-ID: <E18UCLi-0000Wr-00@sc8-sf-web2.sourceforge.net>

Patches item #661092, was opened at 2003-01-02 08:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661092&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: list.sort cmpfunc default

Initial Comment:
It surprised me today when I saw a functional sort written like this:

def sort(sequence, cmpfunc=None):
    sorted = list(sequence)
    if cmpfunc is None:
        sorted.sort()
    else:
        sorted.sort(cmpfunc)
    return sorted

If [].sort() was written in Python its function signature would be declared as above (obviously the body would be different), and the above functional sort could be written as:

def sort(sequence, cmpfunc=None):
    sorted = list(sequence)
    sorted.sort(cmpfunc)
    return sorted

The attached patch supports calling [].sort() with an explicit argument of None.  (No doc change yet. If you approve, I will make that mod.)


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

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-02 14:53

Message:
Logged In: YES 
user_id=44345

Checked in as
    Objects/listobject.c 2.145
    Misc/News 1.592
    Lib/test/test_sort.py 1.3
    Doc/lib/libstdtypes.tex 1.116


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

Comment By: Tim Peters (tim_one)
Date: 2003-01-02 11:13

Message:
Logged In: YES 
user_id=31435

Looks good to me, Skip.  Accepted, & back to you.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-02 10:40

Message:
Logged In: YES 
user_id=33168

The patch looks correct.  You should also add a test if Tim
accepts this.

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-02 10:30

Message:
Logged In: YES 
user_id=44345

Thanks, Neal...  

*sigh*  I guess I didn't get the memo.  When I submitted the patch, I saw that the return screen was blank.  I checked a bit later to see if a patch had been created, but didn't think to check if the file was uploaded.  I'll check this time.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-02 10:19

Message:
Logged In: YES 
user_id=33168

Skip, there's no file attached.  Unfortunately, SF doesn't
upload the file any more when submitting a new patch.

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

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


From noreply@sourceforge.net  Thu Jan  2 23:03:43 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 15:03:43 -0800
Subject: [Patches] [ python-Patches-661368 ] Add sysexits.h EX_* symbols to posix
Message-ID: <E18UENL-00022m-00@sc8-sf-web4.sourceforge.net>

Patches item #661368, was opened at 2003-01-02 18:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661368&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Martin v. Löwis (loewis)
Summary: Add sysexits.h EX_* symbols to posix

Initial Comment:
The following patch adds the EX_* symbols to the posix
module (exposed through os of course).  These are
defined in sysexits.h.  Done this way since the list
can be (slightly) different depending on the OS.  This
patch includes configure updates to detect sysexits.h.

I'll update docs if it's approved for Py2.3.

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

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


From noreply@sourceforge.net  Thu Jan  2 23:15:43 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 15:15:43 -0800
Subject: [Patches] [ python-Patches-661368 ] Add sysexits.h EX_* symbols to posix
Message-ID: <E18UEYx-0002gS-00@sc8-sf-web3.sourceforge.net>

Patches item #661368, was opened at 2003-01-03 00:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661368&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Martin v. Löwis (loewis)
Summary: Add sysexits.h EX_* symbols to posix

Initial Comment:
The following patch adds the EX_* symbols to the posix
module (exposed through os of course).  These are
defined in sysexits.h.  Done this way since the list
can be (slightly) different depending on the OS.  This
patch includes configure updates to detect sysexits.h.

I'll update docs if it's approved for Py2.3.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 00:15

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Thu Jan  2 23:25:12 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 15:25:12 -0800
Subject: [Patches] [ python-Patches-661281 ] reverse method for string objects.
Message-ID: <E18UEi8-0002if-00@sc8-sf-web4.sourceforge.net>

Patches item #661281, was opened at 2003-01-02 21:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661281&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Wojtek Walczak (gminick)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse method for string objects.

Initial Comment:
Well, in python 2.3a1 you can reverse a string in dozens of ways, for example:
>>> a = 'string'
>>> a[::-1]
'gnirts'
>>> reduce(lambda x,y: y+x, a)
'gnirts'
>>> b = list(a)
>>> b.reverse()
>>> "".join(b)
'gnirts'
but there's no simple method as function reverse() in plenty of languages. That patch changes that situation by adding reverse method to Objects/stringobject.c
Tested on Linux 2.4.5 with Python2.3alpha1 with i586 platform.
Feel free to improve that or throw it away :)

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 00:25

Message:
Logged In: YES 
user_id=21627

-1. How often do you need to reverse a string, outside
assignments for programming course? For the latter purpose,
it would actually hurt if Python provided a method for that.

What other languages have builtin reversal of strings?

In addition, your patch is wrong: it leaks len bytes per call.

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

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


From noreply@sourceforge.net  Thu Jan  2 23:46:09 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 15:46:09 -0800
Subject: [Patches] [ python-Patches-661368 ] Add sysexits.h EX_* symbols to posix
Message-ID: <E18UF2P-0007LQ-00@sc8-sf-web2.sourceforge.net>

Patches item #661368, was opened at 2003-01-02 18:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661368&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Martin v. Löwis (loewis)
Summary: Add sysexits.h EX_* symbols to posix

Initial Comment:
The following patch adds the EX_* symbols to the posix
module (exposed through os of course).  These are
defined in sysexits.h.  Done this way since the list
can be (slightly) different depending on the OS.  This
patch includes configure updates to detect sysexits.h.

I'll update docs if it's approved for Py2.3.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-02 18:46

Message:
Logged In: YES 
user_id=12800

I know all about this PITA, thought I had, guess I didn't. ;(

Trying again...

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-02 18:15

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Fri Jan  3 00:03:51 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 16:03:51 -0800
Subject: [Patches] [ python-Patches-661368 ] Add sysexits.h EX_* symbols to posix
Message-ID: <E18UFJX-0007nv-00@sc8-sf-web2.sourceforge.net>

Patches item #661368, was opened at 2003-01-03 00:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661368&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Martin v. Löwis (loewis)
Summary: Add sysexits.h EX_* symbols to posix

Initial Comment:
The following patch adds the EX_* symbols to the posix
module (exposed through os of course).  These are
defined in sysexits.h.  Done this way since the list
can be (slightly) different depending on the OS.  This
patch includes configure updates to detect sysexits.h.

I'll update docs if it's approved for Py2.3.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 01:03

Message:
Logged In: YES 
user_id=21627

Never heard about sysexit.h... The patch looks fine, except
that the list of headers to test should be roughly in
alphabetical order (so that it is easier to spot
duplicates). Please apply it.

In general, there is no need to attach the generated
configure to SF bug reports, it will outdate quickly.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-03 00:46

Message:
Logged In: YES 
user_id=12800

I know all about this PITA, thought I had, guess I didn't. ;(

Trying again...

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 00:15

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Fri Jan  3 00:04:36 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 16:04:36 -0800
Subject: [Patches] [ python-Patches-661368 ] Add sysexits.h EX_* symbols to posix
Message-ID: <E18UFKG-0007op-00@sc8-sf-web2.sourceforge.net>

Patches item #661368, was opened at 2003-01-03 00:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661368&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Add sysexits.h EX_* symbols to posix

Initial Comment:
The following patch adds the EX_* symbols to the posix
module (exposed through os of course).  These are
defined in sysexits.h.  Done this way since the list
can be (slightly) different depending on the OS.  This
patch includes configure updates to detect sysexits.h.

I'll update docs if it's approved for Py2.3.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 01:03

Message:
Logged In: YES 
user_id=21627

Never heard about sysexit.h... The patch looks fine, except
that the list of headers to test should be roughly in
alphabetical order (so that it is easier to spot
duplicates). Please apply it.

In general, there is no need to attach the generated
configure to SF bug reports, it will outdate quickly.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-03 00:46

Message:
Logged In: YES 
user_id=12800

I know all about this PITA, thought I had, guess I didn't. ;(

Trying again...

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 00:15

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Fri Jan  3 02:58:38 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 18:58:38 -0800
Subject: [Patches] [ python-Patches-661368 ] Add sysexits.h EX_* symbols to posix
Message-ID: <E18UI2g-0001HL-00@sc8-sf-web3.sourceforge.net>

Patches item #661368, was opened at 2003-01-02 18:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661368&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Add sysexits.h EX_* symbols to posix

Initial Comment:
The following patch adds the EX_* symbols to the posix
module (exposed through os of course).  These are
defined in sysexits.h.  Done this way since the list
can be (slightly) different depending on the OS.  This
patch includes configure updates to detect sysexits.h.

I'll update docs if it's approved for Py2.3.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-02 21:58

Message:
Logged In: YES 
user_id=12800

The order is roughly the order found in Linux's sysexits.h,
which is in numerical order (there is one extra symbol found
in Solaris's sysexit.h that isn't in Linux's).

I'll work out doc updates before I commit.  Thanks for
looking at it.  The configure goo was because I didn't trim
my "cvs diff -u" output. ;)

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-02 19:03

Message:
Logged In: YES 
user_id=21627

Never heard about sysexit.h... The patch looks fine, except
that the list of headers to test should be roughly in
alphabetical order (so that it is easier to spot
duplicates). Please apply it.

In general, there is no need to attach the generated
configure to SF bug reports, it will outdate quickly.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-02 18:46

Message:
Logged In: YES 
user_id=12800

I know all about this PITA, thought I had, guess I didn't. ;(

Trying again...

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-02 18:15

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Fri Jan  3 02:59:48 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 18:59:48 -0800
Subject: [Patches] [ python-Patches-661437 ] apply() should get PendingDeprecation
Message-ID: <E18UI3o-0001JK-00@sc8-sf-web3.sourceforge.net>

Patches item #661437, was opened at 2003-01-02 21:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661437&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: apply() should get PendingDeprecation

Initial Comment:
Submitting this so I don't forget about it <wink>.

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

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


From noreply@sourceforge.net  Fri Jan  3 03:06:59 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 19:06:59 -0800
Subject: [Patches] [ python-Patches-661440 ] Refactor and streamline PyCFunction_Call
Message-ID: <E18UIAl-000773-00@sc8-sf-web1.sourceforge.net>

Patches item #661440, was opened at 2003-01-02 22:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661440&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Refactor and streamline PyCFunction_Call

Initial Comment:
Refactor PyCFunction_Call with an eye towards 
clarity and speed while leaving the semantics 
unchanged.  

It is now obvious which combinations of flags are 
allowed; the new structure makes it easier to add new 
flags and flag combinations; and every path runs 
faster (by having fewer jumps, filling variables only 
when and where needed, and by merging a test into 
the switch logic).

* Incorporated the keyword flag test into switch/case.
* Deferred initialization of "size" until when and where 
needed.
* Inverted error tests so that the common case has 
no jumps.



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

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


From noreply@sourceforge.net  Fri Jan  3 07:12:20 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Jan 2003 23:12:20 -0800
Subject: [Patches] [ python-Patches-660559 ] Use METH_O and METH_NOARGS where possible
Message-ID: <E18UM0C-0007MS-00@sc8-sf-web3.sourceforge.net>

Patches item #660559, was opened at 2002-12-31 15:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660559&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Martin v. Löwis (loewis)
Summary: Use METH_O and METH_NOARGS where possible

Initial Comment:
Speed-up calls and tighten code in operator.c 
arraymodule.c, and cStringIO.c by using METH_O, 
METH_NOARGS and PyArg_UnpackTuple.

Didn't touch other modules that I wasn't familiar with 
or that didn't look like they would benefit from the 
speedup.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-01-02 23:12

Message:
Logged In: YES 
user_id=357491

So I just finished reading the diff and it all looks good to
me (I think).  I basically just read through the diff and
when I saw  the original I tried to guess how Raymond
changed it and see what he did, in fact, change it to in the
end.  All turned out the way I expected it.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-01 18:27

Message:
Logged In: YES 
user_id=80475

Fixed.  Revised patch attached.

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

Comment By: Tim Peters (tim_one)
Date: 2003-01-01 17:52

Message:
Logged In: YES 
user_id=31435

Note that a METH_NOARGS function is still called, at the C 
level, with two arguments.  The second argument is always 
NULL, and sooner or later some platform C is going to blow 
up when that's passed to a function declared to take only 
one argument ("the usual" cast to PyCFunction shuts up the 
compile-time warnings).

It's not your job to fix that everywhere, but new uses of 
METH_NOARGS shouldn't add to this problem.  Declaring a 
second PyObject * argument with a name like "unused" 
or "dummy" would be fine.

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

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


From noreply@sourceforge.net  Fri Jan  3 08:10:56 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 00:10:56 -0800
Subject: [Patches] [ python-Patches-661368 ] Add sysexits.h EX_* symbols to posix
Message-ID: <E18UMuu-0000U8-00@sc8-sf-web3.sourceforge.net>

Patches item #661368, was opened at 2003-01-03 00:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661368&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Add sysexits.h EX_* symbols to posix

Initial Comment:
The following patch adds the EX_* symbols to the posix
module (exposed through os of course).  These are
defined in sysexits.h.  Done this way since the list
can be (slightly) different depending on the OS.  This
patch includes configure updates to detect sysexits.h.

I'll update docs if it's approved for Py2.3.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 09:10

Message:
Logged In: YES 
user_id=21627

I'm not concerned about the order of symbols in posixmodule,
but about the order of header names in configure.in - those
should be alphabetical.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-03 03:58

Message:
Logged In: YES 
user_id=12800

The order is roughly the order found in Linux's sysexits.h,
which is in numerical order (there is one extra symbol found
in Solaris's sysexit.h that isn't in Linux's).

I'll work out doc updates before I commit.  Thanks for
looking at it.  The configure goo was because I didn't trim
my "cvs diff -u" output. ;)

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 01:03

Message:
Logged In: YES 
user_id=21627

Never heard about sysexit.h... The patch looks fine, except
that the list of headers to test should be roughly in
alphabetical order (so that it is easier to spot
duplicates). Please apply it.

In general, there is no need to attach the generated
configure to SF bug reports, it will outdate quickly.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-03 00:46

Message:
Logged In: YES 
user_id=12800

I know all about this PITA, thought I had, guess I didn't. ;(

Trying again...

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 00:15

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Fri Jan  3 08:13:50 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 00:13:50 -0800
Subject: [Patches] [ python-Patches-660559 ] Use METH_O and METH_NOARGS where possible
Message-ID: <E18UMxi-0000mb-00@sc8-sf-web4.sourceforge.net>

Patches item #660559, was opened at 2003-01-01 00:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660559&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Use METH_O and METH_NOARGS where possible

Initial Comment:
Speed-up calls and tighten code in operator.c 
arraymodule.c, and cStringIO.c by using METH_O, 
METH_NOARGS and PyArg_UnpackTuple.

Didn't touch other modules that I wasn't familiar with 
or that didn't look like they would benefit from the 
speedup.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 09:13

Message:
Logged In: YES 
user_id=21627

I agree that the patch looks fine; Raymond, please apply it.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-01-03 08:12

Message:
Logged In: YES 
user_id=357491

So I just finished reading the diff and it all looks good to
me (I think).  I basically just read through the diff and
when I saw  the original I tried to guess how Raymond
changed it and see what he did, in fact, change it to in the
end.  All turned out the way I expected it.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-02 03:27

Message:
Logged In: YES 
user_id=80475

Fixed.  Revised patch attached.

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

Comment By: Tim Peters (tim_one)
Date: 2003-01-02 02:52

Message:
Logged In: YES 
user_id=31435

Note that a METH_NOARGS function is still called, at the C 
level, with two arguments.  The second argument is always 
NULL, and sooner or later some platform C is going to blow 
up when that's passed to a function declared to take only 
one argument ("the usual" cast to PyCFunction shuts up the 
compile-time warnings).

It's not your job to fix that everywhere, but new uses of 
METH_NOARGS shouldn't add to this problem.  Declaring a 
second PyObject * argument with a name like "unused" 
or "dummy" would be fine.

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

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


From noreply@sourceforge.net  Fri Jan  3 08:18:46 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 00:18:46 -0800
Subject: [Patches] [ python-Patches-661281 ] reverse method for string objects.
Message-ID: <E18UN2U-0000wi-00@sc8-sf-web4.sourceforge.net>

Patches item #661281, was opened at 2003-01-02 15:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661281&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Wojtek Walczak (gminick)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse method for string objects.

Initial Comment:
Well, in python 2.3a1 you can reverse a string in dozens of ways, for example:
>>> a = 'string'
>>> a[::-1]
'gnirts'
>>> reduce(lambda x,y: y+x, a)
'gnirts'
>>> b = list(a)
>>> b.reverse()
>>> "".join(b)
'gnirts'
but there's no simple method as function reverse() in plenty of languages. That patch changes that situation by adding reverse method to Objects/stringobject.c
Tested on Linux 2.4.5 with Python2.3alpha1 with i586 platform.
Feel free to improve that or throw it away :)

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 03:18

Message:
Logged In: YES 
user_id=80475

This has been proposed and rejected before.  The reasons 
were lack of non-toy use cases (though somebody actually 
found one or two real world examples), its value as 
classroom exercise, and avoiding interface bloat.

Now, with the "string"[::-1], there is even less of a case for 
reverse (TOOWTDI).

With apologies, marking as rejected and closing the 
patch.  Future patches and bug fixes are always 
welcomem as are any efforts to contribute.  Even if a 
patch doesn't get accepted, it is appreciated.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-02 18:25

Message:
Logged In: YES 
user_id=21627

-1. How often do you need to reverse a string, outside
assignments for programming course? For the latter purpose,
it would actually hurt if Python provided a method for that.

What other languages have builtin reversal of strings?

In addition, your patch is wrong: it leaks len bytes per call.

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

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


From noreply@sourceforge.net  Fri Jan  3 08:28:34 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 00:28:34 -0800
Subject: [Patches] [ python-Patches-660559 ] Use METH_O and METH_NOARGS where possible
Message-ID: <E18UNBy-00070v-00@sc8-sf-web1.sourceforge.net>

Patches item #660559, was opened at 2002-12-31 18:19
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660559&group_id=5470

Category: Modules
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Use METH_O and METH_NOARGS where possible

Initial Comment:
Speed-up calls and tighten code in operator.c 
arraymodule.c, and cStringIO.c by using METH_O, 
METH_NOARGS and PyArg_UnpackTuple.

Didn't touch other modules that I wasn't familiar with 
or that didn't look like they would benefit from the 
speedup.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 03:28

Message:
Logged In: YES 
user_id=80475

Checked in as: arraymodule.c 2.80, cStringIO.c 2.39,and 
operator.c 2.26.

Thank you Tim, Brett, and Martin for the quality control.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 03:13

Message:
Logged In: YES 
user_id=21627

I agree that the patch looks fine; Raymond, please apply it.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-01-03 02:12

Message:
Logged In: YES 
user_id=357491

So I just finished reading the diff and it all looks good to
me (I think).  I basically just read through the diff and
when I saw  the original I tried to guess how Raymond
changed it and see what he did, in fact, change it to in the
end.  All turned out the way I expected it.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-01 21:27

Message:
Logged In: YES 
user_id=80475

Fixed.  Revised patch attached.

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

Comment By: Tim Peters (tim_one)
Date: 2003-01-01 20:52

Message:
Logged In: YES 
user_id=31435

Note that a METH_NOARGS function is still called, at the C 
level, with two arguments.  The second argument is always 
NULL, and sooner or later some platform C is going to blow 
up when that's passed to a function declared to take only 
one argument ("the usual" cast to PyCFunction shuts up the 
compile-time warnings).

It's not your job to fix that everywhere, but new uses of 
METH_NOARGS shouldn't add to this problem.  Declaring a 
second PyObject * argument with a name like "unused" 
or "dummy" would be fine.

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

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


From noreply@sourceforge.net  Fri Jan  3 08:29:00 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 00:29:00 -0800
Subject: [Patches] [ python-Patches-661281 ] reverse method for string objects.
Message-ID: <E18UNCO-0001LD-00@sc8-sf-web4.sourceforge.net>

Patches item #661281, was opened at 2003-01-02 21:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661281&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Wojtek Walczak (gminick)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse method for string objects.

Initial Comment:
Well, in python 2.3a1 you can reverse a string in dozens of ways, for example:
>>> a = 'string'
>>> a[::-1]
'gnirts'
>>> reduce(lambda x,y: y+x, a)
'gnirts'
>>> b = list(a)
>>> b.reverse()
>>> "".join(b)
'gnirts'
but there's no simple method as function reverse() in plenty of languages. That patch changes that situation by adding reverse method to Objects/stringobject.c
Tested on Linux 2.4.5 with Python2.3alpha1 with i586 platform.
Feel free to improve that or throw it away :)

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

>Comment By: Wojtek Walczak (gminick)
Date: 2003-01-03 09:29

Message:
Logged In: YES 
user_id=679226

loewis wrote:
> What other languages have builtin reversal of strings?
For example ruby ;] (...but, well, looks like it really 
isn't too important method, i'll try to think about something
more useful). 

> In addition, your patch is wrong: it leaks len bytes per 
> call.
OK, can you tell me how to change that?

ps. in the world of python developers I'm new, so hi everyone  ;)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 09:18

Message:
Logged In: YES 
user_id=80475

This has been proposed and rejected before.  The reasons 
were lack of non-toy use cases (though somebody actually 
found one or two real world examples), its value as 
classroom exercise, and avoiding interface bloat.

Now, with the "string"[::-1], there is even less of a case for 
reverse (TOOWTDI).

With apologies, marking as rejected and closing the 
patch.  Future patches and bug fixes are always 
welcomem as are any efforts to contribute.  Even if a 
patch doesn't get accepted, it is appreciated.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 00:25

Message:
Logged In: YES 
user_id=21627

-1. How often do you need to reverse a string, outside
assignments for programming course? For the latter purpose,
it would actually hurt if Python provided a method for that.

What other languages have builtin reversal of strings?

In addition, your patch is wrong: it leaks len bytes per call.

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

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


From noreply@sourceforge.net  Fri Jan  3 08:51:04 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 00:51:04 -0800
Subject: [Patches] [ python-Patches-661281 ] reverse method for string objects.
Message-ID: <E18UNXk-0004XN-00@sc8-sf-web2.sourceforge.net>

Patches item #661281, was opened at 2003-01-02 15:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661281&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Wojtek Walczak (gminick)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse method for string objects.

Initial Comment:
Well, in python 2.3a1 you can reverse a string in dozens of ways, for example:
>>> a = 'string'
>>> a[::-1]
'gnirts'
>>> reduce(lambda x,y: y+x, a)
'gnirts'
>>> b = list(a)
>>> b.reverse()
>>> "".join(b)
'gnirts'
but there's no simple method as function reverse() in plenty of languages. That patch changes that situation by adding reverse method to Objects/stringobject.c
Tested on Linux 2.4.5 with Python2.3alpha1 with i586 platform.
Feel free to improve that or throw it away :)

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 03:51

Message:
Logged In: YES 
user_id=80475

For educational purposes, here are a few thoughts.

* the malloc for "old" is not used and the memory for it is 
permanently lost when overwritten by 
PyString_AS_STRING.

* PyString_AS_STRING returns a pointer to an existing 
buffer which should not be altered, reference counted, or 
freed (per 7.3.1 of the C API manual).

* In general, malloc() should not be used, PyMem_Alloc 
and Free are their Python managed counterparts.

* Use SF's search box (under feature requests) to find 
previous discussions and reviews.  This will make sure 
that your not proposing an idea that has already been 
discussed and rejected.  In this case, see feature request 
494240.

* A good way to get started making contributions is to 
study and make review comments on other people's 
patches or to propose bug fixes.

* FYI, the discussions can continue even after a patch is 
closed (it doesn't need to be re-opened for that).

Hope this is of some help to you.

Looking forward to your future contributions.





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

Comment By: Wojtek Walczak (gminick)
Date: 2003-01-03 03:29

Message:
Logged In: YES 
user_id=679226

loewis wrote:
> What other languages have builtin reversal of strings?
For example ruby ;] (...but, well, looks like it really 
isn't too important method, i'll try to think about something
more useful). 

> In addition, your patch is wrong: it leaks len bytes per 
> call.
OK, can you tell me how to change that?

ps. in the world of python developers I'm new, so hi everyone  ;)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 03:18

Message:
Logged In: YES 
user_id=80475

This has been proposed and rejected before.  The reasons 
were lack of non-toy use cases (though somebody actually 
found one or two real world examples), its value as 
classroom exercise, and avoiding interface bloat.

Now, with the "string"[::-1], there is even less of a case for 
reverse (TOOWTDI).

With apologies, marking as rejected and closing the 
patch.  Future patches and bug fixes are always 
welcomem as are any efforts to contribute.  Even if a 
patch doesn't get accepted, it is appreciated.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-02 18:25

Message:
Logged In: YES 
user_id=21627

-1. How often do you need to reverse a string, outside
assignments for programming course? For the latter purpose,
it would actually hurt if Python provided a method for that.

What other languages have builtin reversal of strings?

In addition, your patch is wrong: it leaks len bytes per call.

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

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


From noreply@sourceforge.net  Fri Jan  3 09:01:43 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 01:01:43 -0800
Subject: [Patches] [ python-Patches-661281 ] reverse method for string objects.
Message-ID: <E18UNi3-0004lo-00@sc8-sf-web2.sourceforge.net>

Patches item #661281, was opened at 2003-01-02 21:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661281&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Wojtek Walczak (gminick)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse method for string objects.

Initial Comment:
Well, in python 2.3a1 you can reverse a string in dozens of ways, for example:
>>> a = 'string'
>>> a[::-1]
'gnirts'
>>> reduce(lambda x,y: y+x, a)
'gnirts'
>>> b = list(a)
>>> b.reverse()
>>> "".join(b)
'gnirts'
but there's no simple method as function reverse() in plenty of languages. That patch changes that situation by adding reverse method to Objects/stringobject.c
Tested on Linux 2.4.5 with Python2.3alpha1 with i586 platform.
Feel free to improve that or throw it away :)

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 10:01

Message:
Logged In: YES 
user_id=21627

I think the patch got reopened as Raymond's and Woijtek's
edits have crossed; last writer wins on SF. So closing it again.

Wojtek, there are really many ways to contribute. I see
three (not necessarily identical) sources of ideas:

1. Do what Python maintainers would appreciate.
    Look at the existing feature requests, and try to
provide those 
    features. Look at the existing bug reports, and try to
fix those 
    bugs.

2. Do what users would want to see.
    For that, you probably have to watch comp.lang.python; if 
    somebody has some idea which isn't outright rejected by
    others, see whether you can work with the poster to provide 
    that feature.

3. Implement what you would use yourself
   I'm not sure whether the string.reverse would fall into that
   category; I'm rather thinking that if you find annoyances
when
   writing Python applications, you could consider contributing.
   In some cases, it might still be better to solve the problem 
   outside Python; it takes some experience to learn when
   modifying Python is appropriate (and opinions vary. Hi 
   Rayomond :-)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 09:51

Message:
Logged In: YES 
user_id=80475

For educational purposes, here are a few thoughts.

* the malloc for "old" is not used and the memory for it is 
permanently lost when overwritten by 
PyString_AS_STRING.

* PyString_AS_STRING returns a pointer to an existing 
buffer which should not be altered, reference counted, or 
freed (per 7.3.1 of the C API manual).

* In general, malloc() should not be used, PyMem_Alloc 
and Free are their Python managed counterparts.

* Use SF's search box (under feature requests) to find 
previous discussions and reviews.  This will make sure 
that your not proposing an idea that has already been 
discussed and rejected.  In this case, see feature request 
494240.

* A good way to get started making contributions is to 
study and make review comments on other people's 
patches or to propose bug fixes.

* FYI, the discussions can continue even after a patch is 
closed (it doesn't need to be re-opened for that).

Hope this is of some help to you.

Looking forward to your future contributions.





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

Comment By: Wojtek Walczak (gminick)
Date: 2003-01-03 09:29

Message:
Logged In: YES 
user_id=679226

loewis wrote:
> What other languages have builtin reversal of strings?
For example ruby ;] (...but, well, looks like it really 
isn't too important method, i'll try to think about something
more useful). 

> In addition, your patch is wrong: it leaks len bytes per 
> call.
OK, can you tell me how to change that?

ps. in the world of python developers I'm new, so hi everyone  ;)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 09:18

Message:
Logged In: YES 
user_id=80475

This has been proposed and rejected before.  The reasons 
were lack of non-toy use cases (though somebody actually 
found one or two real world examples), its value as 
classroom exercise, and avoiding interface bloat.

Now, with the "string"[::-1], there is even less of a case for 
reverse (TOOWTDI).

With apologies, marking as rejected and closing the 
patch.  Future patches and bug fixes are always 
welcomem as are any efforts to contribute.  Even if a 
patch doesn't get accepted, it is appreciated.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 00:25

Message:
Logged In: YES 
user_id=21627

-1. How often do you need to reverse a string, outside
assignments for programming course? For the latter purpose,
it would actually hurt if Python provided a method for that.

What other languages have builtin reversal of strings?

In addition, your patch is wrong: it leaks len bytes per call.

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

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


From noreply@sourceforge.net  Fri Jan  3 09:24:25 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 01:24:25 -0800
Subject: [Patches] [ python-Patches-661281 ] reverse method for string objects.
Message-ID: <E18UO41-0003CP-00@sc8-sf-web4.sourceforge.net>

Patches item #661281, was opened at 2003-01-02 21:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661281&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Wojtek Walczak (gminick)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse method for string objects.

Initial Comment:
Well, in python 2.3a1 you can reverse a string in dozens of ways, for example:
>>> a = 'string'
>>> a[::-1]
'gnirts'
>>> reduce(lambda x,y: y+x, a)
'gnirts'
>>> b = list(a)
>>> b.reverse()
>>> "".join(b)
'gnirts'
but there's no simple method as function reverse() in plenty of languages. That patch changes that situation by adding reverse method to Objects/stringobject.c
Tested on Linux 2.4.5 with Python2.3alpha1 with i586 platform.
Feel free to improve that or throw it away :)

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

>Comment By: Wojtek Walczak (gminick)
Date: 2003-01-03 10:24

Message:
Logged In: YES 
user_id=679226

Big thanks Raymond, your help is really appreciated.
See you in the next patch discussion, but next time I'll do my homework ;)

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 10:01

Message:
Logged In: YES 
user_id=21627

I think the patch got reopened as Raymond's and Woijtek's
edits have crossed; last writer wins on SF. So closing it again.

Wojtek, there are really many ways to contribute. I see
three (not necessarily identical) sources of ideas:

1. Do what Python maintainers would appreciate.
    Look at the existing feature requests, and try to
provide those 
    features. Look at the existing bug reports, and try to
fix those 
    bugs.

2. Do what users would want to see.
    For that, you probably have to watch comp.lang.python; if 
    somebody has some idea which isn't outright rejected by
    others, see whether you can work with the poster to provide 
    that feature.

3. Implement what you would use yourself
   I'm not sure whether the string.reverse would fall into that
   category; I'm rather thinking that if you find annoyances
when
   writing Python applications, you could consider contributing.
   In some cases, it might still be better to solve the problem 
   outside Python; it takes some experience to learn when
   modifying Python is appropriate (and opinions vary. Hi 
   Rayomond :-)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 09:51

Message:
Logged In: YES 
user_id=80475

For educational purposes, here are a few thoughts.

* the malloc for "old" is not used and the memory for it is 
permanently lost when overwritten by 
PyString_AS_STRING.

* PyString_AS_STRING returns a pointer to an existing 
buffer which should not be altered, reference counted, or 
freed (per 7.3.1 of the C API manual).

* In general, malloc() should not be used, PyMem_Alloc 
and Free are their Python managed counterparts.

* Use SF's search box (under feature requests) to find 
previous discussions and reviews.  This will make sure 
that your not proposing an idea that has already been 
discussed and rejected.  In this case, see feature request 
494240.

* A good way to get started making contributions is to 
study and make review comments on other people's 
patches or to propose bug fixes.

* FYI, the discussions can continue even after a patch is 
closed (it doesn't need to be re-opened for that).

Hope this is of some help to you.

Looking forward to your future contributions.





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

Comment By: Wojtek Walczak (gminick)
Date: 2003-01-03 09:29

Message:
Logged In: YES 
user_id=679226

loewis wrote:
> What other languages have builtin reversal of strings?
For example ruby ;] (...but, well, looks like it really 
isn't too important method, i'll try to think about something
more useful). 

> In addition, your patch is wrong: it leaks len bytes per 
> call.
OK, can you tell me how to change that?

ps. in the world of python developers I'm new, so hi everyone  ;)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 09:18

Message:
Logged In: YES 
user_id=80475

This has been proposed and rejected before.  The reasons 
were lack of non-toy use cases (though somebody actually 
found one or two real world examples), its value as 
classroom exercise, and avoiding interface bloat.

Now, with the "string"[::-1], there is even less of a case for 
reverse (TOOWTDI).

With apologies, marking as rejected and closing the 
patch.  Future patches and bug fixes are always 
welcomem as are any efforts to contribute.  Even if a 
patch doesn't get accepted, it is appreciated.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 00:25

Message:
Logged In: YES 
user_id=21627

-1. How often do you need to reverse a string, outside
assignments for programming course? For the latter purpose,
it would actually hurt if Python provided a method for that.

What other languages have builtin reversal of strings?

In addition, your patch is wrong: it leaks len bytes per call.

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

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


From noreply@sourceforge.net  Fri Jan  3 10:19:08 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 02:19:08 -0800
Subject: [Patches] [ python-Patches-661440 ] Refactor and streamline PyCFunction_Call
Message-ID: <E18UOuy-0001v1-00@sc8-sf-web1.sourceforge.net>

Patches item #661440, was opened at 2003-01-02 22:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661440&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Martin v. Löwis (loewis)
Summary: Refactor and streamline PyCFunction_Call

Initial Comment:
Refactor PyCFunction_Call with an eye towards 
clarity and speed while leaving the semantics 
unchanged.  

It is now obvious which combinations of flags are 
allowed; the new structure makes it easier to add new 
flags and flag combinations; and every path runs 
faster (by having fewer jumps, filling variables only 
when and where needed, and by merging a test into 
the switch logic).

* Incorporated the keyword flag test into switch/case.
* Deferred initialization of "size" until when and where 
needed.
* Inverted error tests so that the common case has 
no jumps.



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 05:19

Message:
Logged In: YES 
user_id=80475

Should've been assigned to Martin who wrote some of the 
existing code for that function.

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

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


From noreply@sourceforge.net  Fri Jan  3 10:32:09 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 02:32:09 -0800
Subject: [Patches] [ python-Patches-661536 ] handle unary op of constant in transformer.py
Message-ID: <E18UP7Z-0002L1-00@sc8-sf-web1.sourceforge.net>

Patches item #661536, was opened at 2003-01-03 10:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661536&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Jeremy Hylton (jhylton)
Summary: handle unary op of constant in transformer.py

Initial Comment:
This fixes the only known (to me) remaining wart in the
compiler package.

It's a horrible patch, but I'm reasonably confident
it's an accurate reflection of the corresponding bit of
compile.c <wink>.

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

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


From noreply@sourceforge.net  Fri Jan  3 10:40:02 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 02:40:02 -0800
Subject: [Patches] [ python-Patches-661440 ] Refactor and streamline PyCFunction_Call
Message-ID: <E18UPFC-00062u-00@sc8-sf-web4.sourceforge.net>

Patches item #661440, was opened at 2003-01-03 04:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661440&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Martin v. Löwis (loewis)
Summary: Refactor and streamline PyCFunction_Call

Initial Comment:
Refactor PyCFunction_Call with an eye towards 
clarity and speed while leaving the semantics 
unchanged.  

It is now obvious which combinations of flags are 
allowed; the new structure makes it easier to add new 
flags and flag combinations; and every path runs 
faster (by having fewer jumps, filling variables only 
when and where needed, and by merging a test into 
the switch logic).

* Incorporated the keyword flag test into switch/case.
* Deferred initialization of "size" until when and where 
needed.
* Inverted error tests so that the common case has 
no jumps.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 11:40

Message:
Logged In: YES 
user_id=21627

I'm uncertain why this makes the function clearer; it
appears to make it merely different, as it duplicates the
test for empty dictionaries, and the computation of the size.



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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 11:19

Message:
Logged In: YES 
user_id=80475

Should've been assigned to Martin who wrote some of the 
existing code for that function.

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

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


From noreply@sourceforge.net  Fri Jan  3 11:12:13 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 03:12:13 -0800
Subject: [Patches] [ python-Patches-642974 ] logging SysLogHandler proto type wrong
Message-ID: <E18UPkL-0007Gh-00@sc8-sf-web4.sourceforge.net>

Patches item #642974, was opened at 2002-11-24 05:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=642974&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging SysLogHandler proto type wrong 

Initial Comment:
The (new) logging module's handlers.SysLogHandler has
an incorrect protocol type when the address is a
file-like object.  It fails during connect as a result.
 A patch is as follows:

--- handlers.py 13 Nov 2002 16:18:29 -0000      1.2
+++ handlers.py 24 Nov 2002 05:36:51 -0000
@@ -348,7 +348,7 @@
         self.address = address
         self.facility = facility
         if type(address) == types.StringType:
-            self.socket =
socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
+            self.socket =
socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM)
             self.socket.connect(address)
             self.unixsocket = 1
         else:


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

Comment By: Vinay Sajip (vsajip)
Date: 2003-01-03 11:12

Message:
Logged In: YES 
user_id=308438

I'm happy to accept the patch, though I cannot test at the 
moment due to a hardware failure of my Linux machine.

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

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


From noreply@sourceforge.net  Fri Jan  3 11:22:58 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 03:22:58 -0800
Subject: [Patches] [ python-Patches-661440 ] Refactor and streamline PyCFunction_Call
Message-ID: <E18UPuk-0007ej-00@sc8-sf-web4.sourceforge.net>

Patches item #661440, was opened at 2003-01-02 22:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661440&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Martin v. Löwis (loewis)
Summary: Refactor and streamline PyCFunction_Call

Initial Comment:
Refactor PyCFunction_Call with an eye towards 
clarity and speed while leaving the semantics 
unchanged.  

It is now obvious which combinations of flags are 
allowed; the new structure makes it easier to add new 
flags and flag combinations; and every path runs 
faster (by having fewer jumps, filling variables only 
when and where needed, and by merging a test into 
the switch logic).

* Incorporated the keyword flag test into switch/case.
* Deferred initialization of "size" until when and where 
needed.
* Inverted error tests so that the common case has 
no jumps.



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 06:22

Message:
Logged In: YES 
user_id=80475

For me, the clarity comes from all allowable flag 
combinations being shown in the switch/case.

The duplication of the test for empty dictionaries and the 
computation of size are done for speed (only being done 
when and where needed).  The duplication is warranted 
only because the function is on the critical path for just 
about everything in Python and here speed really matters.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 05:40

Message:
Logged In: YES 
user_id=21627

I'm uncertain why this makes the function clearer; it
appears to make it merely different, as it duplicates the
test for empty dictionaries, and the computation of the size.



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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 05:19

Message:
Logged In: YES 
user_id=80475

Should've been assigned to Martin who wrote some of the 
existing code for that function.

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

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


From noreply@sourceforge.net  Fri Jan  3 12:57:46 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 04:57:46 -0800
Subject: [Patches] [ python-Patches-661581 ] Remove old code from os.py
Message-ID: <E18UROU-0004MX-00@sc8-sf-web2.sourceforge.net>

Patches item #661581, was opened at 2003-01-03 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661581&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Wilkinson (andrew_j_w)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove old code from os.py

Initial Comment:
lib\os.py contains exec statements that are a reminent 
from Python 1.52b2.

They make it hard to statically anaylse Python 
programs as os is such a core module.

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

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


From noreply@sourceforge.net  Fri Jan  3 13:00:51 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 05:00:51 -0800
Subject: [Patches] [ python-Patches-661583 ] Remove old code from lib\os.py
Message-ID: <E18URRT-0004RJ-00@sc8-sf-web2.sourceforge.net>

Patches item #661583, was opened at 2003-01-03 13:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661583&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Wilkinson (andrew_j_w)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove old code from lib\os.py

Initial Comment:
os.py contains exec statements for NT and CE that are 
left over from Python 1.52b2.

They make it hard to statically anaylse python code os 
is such a core module.

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

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


From noreply@sourceforge.net  Fri Jan  3 13:02:42 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 05:02:42 -0800
Subject: [Patches] [ python-Patches-661581 ] Remove old code from os.py
Message-ID: <E18URTG-0006k3-00@sc8-sf-web1.sourceforge.net>

Patches item #661581, was opened at 2003-01-03 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661581&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Andrew Wilkinson (andrew_j_w)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove old code from os.py

Initial Comment:
lib\os.py contains exec statements that are a reminent 
from Python 1.52b2.

They make it hard to statically anaylse Python 
programs as os is such a core module.

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

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


From noreply@sourceforge.net  Fri Jan  3 13:03:58 2003
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Jan 2003 05:03:58 -0800
Subject: [Patches] [ python-Patches-661583 ] Remove old code from lib\os.py
Message-ID: <E18URUU-0004Yj-00@sc8-sf-web2.sourceforge.net>

Patches item #661583, was opened at 2003-01-03 13:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661583&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 3
Submitted By: Andrew Wilkinson (andrew_j_w)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove old code from lib\os.py

Initial Comment:
os.py contains exec statements for NT and CE that are 
left over from Python 1.52b2.

They make it hard to statically anaylse python code os 
is such a core module.

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

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


From noreply@sourceforge.net  Fri Jan  3 15:43:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 07:43:20 -0800
Subject: [Patches] [ python-Patches-658093 ] Documentation support for PEP 301
Message-ID: <E18UTyi-0002Oj-00@sc8-sf-web2.sourceforge.net>

Patches item #658093, was opened at 2002-12-23 22:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658093&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Richard Jones (richard)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Documentation support for PEP 301

Initial Comment:
This is the patch for dist.tex to document the user-visible 
changes in PEP 301. 
 

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2003-01-03 10:43

Message:
Logged In: YES 
user_id=11375

Checked in and closed; thanks!


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

Comment By: Richard Jones (richard)
Date: 2002-12-27 01:56

Message:
Logged In: YES 
user_id=6405

OK, done. I'm hoping to work on the sf-tracker replacement 
during my xmas holidays :) 
 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-26 13:12

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Fri Jan  3 15:35:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 07:35:50 -0800
Subject: [Patches] [ python-Patches-658094 ] PEP 301 implementation
Message-ID: <E18UTrS-0000uH-00@sc8-sf-web4.sourceforge.net>

Patches item #658094, was opened at 2002-12-23 22:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658094&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Richard Jones (richard)
>Assigned to: A.M. Kuchling (akuchling)
Summary: PEP 301 implementation

Initial Comment:
This is the implementation for PEP 301.   
   
dist.py.patch includes the new handling of the classifiers  
keyword in setup().  
  
register.py implements the metadata upload "register" 
command for distutils. 
 

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2003-01-03 10:35

Message:
Logged In: YES 
user_id=11375

Checked in to the trunk.  

I'll close this patch now; subsequent discussion can now take place on python-dev or catalog-sig.


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

Comment By: Richard Jones (richard)
Date: 2002-12-27 01:54

Message:
Logged In: YES 
user_id=6405

There's now two register.py implementations. The most recent 
one (version 1.13) is the correct one as it has python.org set 
as the default package index server. I don't have permission to 
delete the other. 
 

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

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


From noreply@sourceforge.net  Fri Jan  3 16:59:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 08:59:33 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18UVAT-0004hv-00@sc8-sf-web3.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 16:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

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


From noreply@sourceforge.net  Fri Jan  3 17:06:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 09:06:08 -0800
Subject: [Patches] [ python-Patches-661440 ] Refactor and streamline PyCFunction_Call
Message-ID: <E18UVGq-00058h-00@sc8-sf-web3.sourceforge.net>

Patches item #661440, was opened at 2003-01-03 03:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661440&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Martin v. Löwis (loewis)
Summary: Refactor and streamline PyCFunction_Call

Initial Comment:
Refactor PyCFunction_Call with an eye towards 
clarity and speed while leaving the semantics 
unchanged.  

It is now obvious which combinations of flags are 
allowed; the new structure makes it easier to add new 
flags and flag combinations; and every path runs 
faster (by having fewer jumps, filling variables only 
when and where needed, and by merging a test into 
the switch logic).

* Incorporated the keyword flag test into switch/case.
* Deferred initialization of "size" until when and where 
needed.
* Inverted error tests so that the common case has 
no jumps.



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

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 17:06

Message:
Logged In: YES 
user_id=31392

Do you have any measurements of the speedup?


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 11:22

Message:
Logged In: YES 
user_id=80475

For me, the clarity comes from all allowable flag 
combinations being shown in the switch/case.

The duplication of the test for empty dictionaries and the 
computation of size are done for speed (only being done 
when and where needed).  The duplication is warranted 
only because the function is on the critical path for just 
about everything in Python and here speed really matters.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 10:40

Message:
Logged In: YES 
user_id=21627

I'm uncertain why this makes the function clearer; it
appears to make it merely different, as it duplicates the
test for empty dictionaries, and the computation of the size.



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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 10:19

Message:
Logged In: YES 
user_id=80475

Should've been assigned to Martin who wrote some of the 
existing code for that function.

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

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


From noreply@sourceforge.net  Fri Jan  3 18:14:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 10:14:06 -0800
Subject: [Patches] [ python-Patches-661760 ] Cygwin auto-import module patch
Message-ID: <E18UWKc-0008RQ-00@sc8-sf-web2.sourceforge.net>

Patches item #661760, was opened at 2003-01-03 09:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661760&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: Cygwin auto-import module patch

Initial Comment:
The attached patch enables shared extension
modules to build cleanly under Cygwin without
moving the static initialization of certain function
pointers (i.e., ones exported from the Python
DLL core) to a module initialization function.

Additionally, this patch fixes the modules that
have been changed in the past to accommodate
Cygwin. Specificially, these modules are:

_hotshot.c
_randommodule.c
_tkinter.c
arraymodule.c
bz2module.c
cPickle.c
socketmodule.c

Note that contrary to my recent email to
python-dev, I did *not* make the following
changes:

$ grep '\.tp_.*[ \t]*=' *.c
bz2module.c:    BZ2File_Type.tp_base = &PyFile_Type;
bz2module.c:    BZ2File_Type.tp_new = 
PyFile_Type.tp_new;
posixmodule.c:  StatResultType.tp_new = 
statresult_new;
threadmodule.c: Locktype.tp_doc = lock_doc;
xxsubtype.c:    spamdict_type.tp_base = &PyDict_Type;
xxsubtype.c:    spamlist_type.tp_base = &PyList_Type;


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

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


From noreply@sourceforge.net  Fri Jan  3 18:15:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 10:15:37 -0800
Subject: [Patches] [ python-Patches-661760 ] Cygwin auto-import module patch
Message-ID: <E18UWM5-0008UC-00@sc8-sf-web2.sourceforge.net>

Patches item #661760, was opened at 2003-01-03 09:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661760&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: Cygwin auto-import module patch

Initial Comment:
The attached patch enables shared extension
modules to build cleanly under Cygwin without
moving the static initialization of certain function
pointers (i.e., ones exported from the Python
DLL core) to a module initialization function.

Additionally, this patch fixes the modules that
have been changed in the past to accommodate
Cygwin. Specificially, these modules are:

_hotshot.c
_randommodule.c
_tkinter.c
arraymodule.c
bz2module.c
cPickle.c
socketmodule.c

Note that contrary to my recent email to
python-dev, I did *not* make the following
changes:

$ grep '\.tp_.*[ \t]*=' *.c
bz2module.c:    BZ2File_Type.tp_base = &PyFile_Type;
bz2module.c:    BZ2File_Type.tp_new = 
PyFile_Type.tp_new;
posixmodule.c:  StatResultType.tp_new = 
statresult_new;
threadmodule.c: Locktype.tp_doc = lock_doc;
xxsubtype.c:    spamdict_type.tp_base = &PyDict_Type;
xxsubtype.c:    spamlist_type.tp_base = &PyList_Type;


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

>Comment By: Jason Tishler (jlt63)
Date: 2003-01-03 09:15

Message:
Logged In: YES 
user_id=86216

AFAICT, SF is still broken! I *did* check the upload
checkbox!

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

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


From noreply@sourceforge.net  Fri Jan  3 18:21:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 10:21:25 -0800
Subject: [Patches] [ python-Patches-660524 ] Cygwin datetime module patch
Message-ID: <E18UWRh-0000Gi-00@sc8-sf-web2.sourceforge.net>

Patches item #660524, was opened at 2002-12-31 12:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=660524&group_id=5470

Category: Modules
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Jason Tishler (jlt63)
Summary: Cygwin datetime module patch

Initial Comment:
The attached patch enables the datetime module
to build cleanly under Cygwin.

OK to apply?

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

>Comment By: Jason Tishler (jlt63)
Date: 2003-01-03 09:21

Message:
Logged In: YES 
user_id=86216

This patch has been superseded by patch #661760:
Cygwin auto-import module patch.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 13:24

Message:
Logged In: YES 
user_id=21627

I take the acceptance back, see

http://mail.python.org/pipermail/python-dev/2002-December/031534.html

Please revise the patch appropriately. Also please produce
patches for all prior changes that you made to remove
initialization out of static structures.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 12:50

Message:
Logged In: YES 
user_id=21627

The changes will certainly go into 2.3a2, which is still
weeks ahead (and that will be branched from the mainline,
again); see PEP 283. 2.3a1 is being prepared right now, and
only PythonLabs can make changes to it.

Happy New Year to you, too!


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

Comment By: Jason Tishler (jlt63)
Date: 2002-12-31 12:41

Message:
Logged In: YES 
user_id=86216

> Do you notice that all those changes won't make it
> anymore into 2.3a1?

No.

Will they make it into 2.3?  Or, do I have to wait until 2.3.x?
Or, 2.4?

BTW, I have a nasty test_format SEGV that I have been
fighting with for a while.  I think that it is a Cygwin malloc
problem, but I'm not sure. Do you know of anyone who would
be willing to help?

BTW, Happy New Year!

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 12:32

Message:
Logged In: YES 
user_id=21627

That patch is fine as well.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 12:27

Message:
Logged In: YES 
user_id=21627

Do you notice that all those changes won't make it anymore
into 2.3a1? There is a moratorium on checking in changes
right now, although I'm unsure whether this applies to the
release branch only.

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

Comment By: Jason Tishler (jlt63)
Date: 2002-12-31 12:24

Message:
Logged In: YES 
user_id=86216

I think that SF is screwed up.  Netscape doesn't work either.
It appears that attaching a patch when submitting a new
patch is broken. Adding it later seems to be OK. Sigh...

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

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


From noreply@sourceforge.net  Fri Jan  3 18:47:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 10:47:43 -0800
Subject: [Patches] [ python-Patches-661440 ] Refactor and streamline PyCFunction_Call
Message-ID: <E18UWr9-00015a-00@sc8-sf-web3.sourceforge.net>

Patches item #661440, was opened at 2003-01-02 22:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661440&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Martin v. Löwis (loewis)
Summary: Refactor and streamline PyCFunction_Call

Initial Comment:
Refactor PyCFunction_Call with an eye towards 
clarity and speed while leaving the semantics 
unchanged.  

It is now obvious which combinations of flags are 
allowed; the new structure makes it easier to add new 
flags and flag combinations; and every path runs 
faster (by having fewer jumps, filling variables only 
when and where needed, and by merging a test into 
the switch logic).

* Incorporated the keyword flag test into switch/case.
* Deferred initialization of "size" until when and where 
needed.
* Inverted error tests so that the common case has 
no jumps.



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 13:47

Message:
Logged In: YES 
user_id=80475

Without making dummy C functions and C caller, I can't 
get a timing suite that isolates the improvement.  The 
timing code attached below shows no change.

>From code inspection, it's easy to see the operation count 
go down.  

For meth_o, meth_noargs and meth_oldargs, it saves the 
flags&keywords step and converts a usually-fail-jump if 
into a usually-succeed-nojump. 

For meth_vargs, it saves the size lookup, the 
flags&keywords step, saves the dict-empty test, and 
converts a usually-fail-jump if into a usually-succeed-
nojump.

For the meth_keywords case, it replaces the size lookup, 
the flags&keywords step, and a usually-succeed-no-jump if 
with a single switch/case jump.  Probably, a net wash 
here.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 12:06

Message:
Logged In: YES 
user_id=31392

Do you have any measurements of the speedup?


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 06:22

Message:
Logged In: YES 
user_id=80475

For me, the clarity comes from all allowable flag 
combinations being shown in the switch/case.

The duplication of the test for empty dictionaries and the 
computation of size are done for speed (only being done 
when and where needed).  The duplication is warranted 
only because the function is on the critical path for just 
about everything in Python and here speed really matters.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 05:40

Message:
Logged In: YES 
user_id=21627

I'm uncertain why this makes the function clearer; it
appears to make it merely different, as it duplicates the
test for empty dictionaries, and the computation of the size.



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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 05:19

Message:
Logged In: YES 
user_id=80475

Should've been assigned to Martin who wrote some of the 
existing code for that function.

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

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


From noreply@sourceforge.net  Fri Jan  3 19:22:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 11:22:48 -0800
Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory
Message-ID: <E18UXP6-0002qr-00@sc8-sf-web3.sourceforge.net>

Patches item #661796, was opened at 2003-01-03 14:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: BZ2File leaking fd and memory

Initial Comment:
The attached patch fixes BZ2File() leaking the fd and
PyFileObject* info (name, read ahead buffer) when an
object is deleted.

I'm not sure the patch fixes these problems in the best
way.  It exposes most of the implementation from
fileobject.c::file_dealloc() through a private API
_PyFile_Dealloc().
BZ2File derives from PyFileObject.

Make sure the file: 'empty' exists and do: 

  from bz2 import *

A simple test which demonstrates the problem is:

  for i in range(100000): o = BZ2File('empty') ; del o

Without the patch, you quickly get:

IOError: [Errno 24] Too many open files: 'empty'

You can modify this to:

  for i in range(100000): o = BZ2File('empty') ;
o.close() ; del o

Now you can see the memory leaks.


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

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


From noreply@sourceforge.net  Fri Jan  3 19:46:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 11:46:23 -0800
Subject: [Patches] [ python-Patches-661760 ] Cygwin auto-import module patch
Message-ID: <E18UXlv-00035L-00@sc8-sf-web2.sourceforge.net>

Patches item #661760, was opened at 2003-01-03 19:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661760&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: Cygwin auto-import module patch

Initial Comment:
The attached patch enables shared extension
modules to build cleanly under Cygwin without
moving the static initialization of certain function
pointers (i.e., ones exported from the Python
DLL core) to a module initialization function.

Additionally, this patch fixes the modules that
have been changed in the past to accommodate
Cygwin. Specificially, these modules are:

_hotshot.c
_randommodule.c
_tkinter.c
arraymodule.c
bz2module.c
cPickle.c
socketmodule.c

Note that contrary to my recent email to
python-dev, I did *not* make the following
changes:

$ grep '\.tp_.*[ \t]*=' *.c
bz2module.c:    BZ2File_Type.tp_base = &PyFile_Type;
bz2module.c:    BZ2File_Type.tp_new = 
PyFile_Type.tp_new;
posixmodule.c:  StatResultType.tp_new = 
statresult_new;
threadmodule.c: Locktype.tp_doc = lock_doc;
xxsubtype.c:    spamdict_type.tp_base = &PyDict_Type;
xxsubtype.c:    spamlist_type.tp_base = &PyList_Type;


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 20:46

Message:
Logged In: YES 
user_id=21627

I'm probably missing some magic here: shouldn't there be a
patch to configure.in also to provide the necessary linker
options?

As for the SF breakage: you should file a bug for SF, in the
"alexandria" project. Perhaps better use a support request,
since that gets better attention.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-01-03 19:15

Message:
Logged In: YES 
user_id=86216

AFAICT, SF is still broken! I *did* check the upload
checkbox!

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

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


From noreply@sourceforge.net  Fri Jan  3 19:52:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 11:52:53 -0800
Subject: [Patches] [ python-Patches-661440 ] Refactor and streamline PyCFunction_Call
Message-ID: <E18UXsD-0004Gp-00@sc8-sf-web3.sourceforge.net>

Patches item #661440, was opened at 2003-01-02 22:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661440&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Martin v. Löwis (loewis)
Summary: Refactor and streamline PyCFunction_Call

Initial Comment:
Refactor PyCFunction_Call with an eye towards 
clarity and speed while leaving the semantics 
unchanged.  

It is now obvious which combinations of flags are 
allowed; the new structure makes it easier to add new 
flags and flag combinations; and every path runs 
faster (by having fewer jumps, filling variables only 
when and where needed, and by merging a test into 
the switch logic).

* Incorporated the keyword flag test into switch/case.
* Deferred initialization of "size" until when and where 
needed.
* Inverted error tests so that the common case has 
no jumps.



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 14:52

Message:
Logged In: YES 
user_id=80475

Okay, I improved the timing suite and found about a 5 to 
10% savings (suite attached as dict.diff and timemeth.py):

Case                NewTime        OldTime
--------                --------------         -------------
meth_o             10.60              11.53
meth_vargs      8.13                8.64
meth_noargs    8.08                8.90
meth_var&kw   8.07                8.46

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 13:47

Message:
Logged In: YES 
user_id=80475

Without making dummy C functions and C caller, I can't 
get a timing suite that isolates the improvement.  The 
timing code attached below shows no change.

>From code inspection, it's easy to see the operation count 
go down.  

For meth_o, meth_noargs and meth_oldargs, it saves the 
flags&keywords step and converts a usually-fail-jump if 
into a usually-succeed-nojump. 

For meth_vargs, it saves the size lookup, the 
flags&keywords step, saves the dict-empty test, and 
converts a usually-fail-jump if into a usually-succeed-
nojump.

For the meth_keywords case, it replaces the size lookup, 
the flags&keywords step, and a usually-succeed-no-jump if 
with a single switch/case jump.  Probably, a net wash 
here.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 12:06

Message:
Logged In: YES 
user_id=31392

Do you have any measurements of the speedup?


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 06:22

Message:
Logged In: YES 
user_id=80475

For me, the clarity comes from all allowable flag 
combinations being shown in the switch/case.

The duplication of the test for empty dictionaries and the 
computation of size are done for speed (only being done 
when and where needed).  The duplication is warranted 
only because the function is on the critical path for just 
about everything in Python and here speed really matters.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 05:40

Message:
Logged In: YES 
user_id=21627

I'm uncertain why this makes the function clearer; it
appears to make it merely different, as it duplicates the
test for empty dictionaries, and the computation of the size.



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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 05:19

Message:
Logged In: YES 
user_id=80475

Should've been assigned to Martin who wrote some of the 
existing code for that function.

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

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


From noreply@sourceforge.net  Fri Jan  3 19:57:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 11:57:39 -0800
Subject: [Patches] [ python-Patches-661440 ] Refactor and streamline PyCFunction_Call
Message-ID: <E18UXwp-0004RI-00@sc8-sf-web3.sourceforge.net>

Patches item #661440, was opened at 2003-01-03 03:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661440&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Martin v. Löwis (loewis)
Summary: Refactor and streamline PyCFunction_Call

Initial Comment:
Refactor PyCFunction_Call with an eye towards 
clarity and speed while leaving the semantics 
unchanged.  

It is now obvious which combinations of flags are 
allowed; the new structure makes it easier to add new 
flags and flag combinations; and every path runs 
faster (by having fewer jumps, filling variables only 
when and where needed, and by merging a test into 
the switch logic).

* Incorporated the keyword flag test into switch/case.
* Deferred initialization of "size" until when and where 
needed.
* Inverted error tests so that the common case has 
no jumps.



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

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 19:57

Message:
Logged In: YES 
user_id=31392

Sounds good to me.  The code looks clear enough.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 19:52

Message:
Logged In: YES 
user_id=80475

Okay, I improved the timing suite and found about a 5 to 
10% savings (suite attached as dict.diff and timemeth.py):

Case                NewTime        OldTime
--------                --------------         -------------
meth_o             10.60              11.53
meth_vargs      8.13                8.64
meth_noargs    8.08                8.90
meth_var&kw   8.07                8.46

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 18:47

Message:
Logged In: YES 
user_id=80475

Without making dummy C functions and C caller, I can't 
get a timing suite that isolates the improvement.  The 
timing code attached below shows no change.

>From code inspection, it's easy to see the operation count 
go down.  

For meth_o, meth_noargs and meth_oldargs, it saves the 
flags&keywords step and converts a usually-fail-jump if 
into a usually-succeed-nojump. 

For meth_vargs, it saves the size lookup, the 
flags&keywords step, saves the dict-empty test, and 
converts a usually-fail-jump if into a usually-succeed-
nojump.

For the meth_keywords case, it replaces the size lookup, 
the flags&keywords step, and a usually-succeed-no-jump if 
with a single switch/case jump.  Probably, a net wash 
here.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 17:06

Message:
Logged In: YES 
user_id=31392

Do you have any measurements of the speedup?


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 11:22

Message:
Logged In: YES 
user_id=80475

For me, the clarity comes from all allowable flag 
combinations being shown in the switch/case.

The duplication of the test for empty dictionaries and the 
computation of size are done for speed (only being done 
when and where needed).  The duplication is warranted 
only because the function is on the critical path for just 
about everything in Python and here speed really matters.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 10:40

Message:
Logged In: YES 
user_id=21627

I'm uncertain why this makes the function clearer; it
appears to make it merely different, as it duplicates the
test for empty dictionaries, and the computation of the size.



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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 10:19

Message:
Logged In: YES 
user_id=80475

Should've been assigned to Martin who wrote some of the 
existing code for that function.

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

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


From noreply@sourceforge.net  Fri Jan  3 19:48:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 11:48:26 -0800
Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory
Message-ID: <E18UXnu-0003E9-00@sc8-sf-web2.sourceforge.net>

Patches item #661796, was opened at 2003-01-03 20:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Gustavo Niemeyer (niemeyer)
Summary: BZ2File leaking fd and memory

Initial Comment:
The attached patch fixes BZ2File() leaking the fd and
PyFileObject* info (name, read ahead buffer) when an
object is deleted.

I'm not sure the patch fixes these problems in the best
way.  It exposes most of the implementation from
fileobject.c::file_dealloc() through a private API
_PyFile_Dealloc().
BZ2File derives from PyFileObject.

Make sure the file: 'empty' exists and do: 

  from bz2 import *

A simple test which demonstrates the problem is:

  for i in range(100000): o = BZ2File('empty') ; del o

Without the patch, you quickly get:

IOError: [Errno 24] Too many open files: 'empty'

You can modify this to:

  for i in range(100000): o = BZ2File('empty') ;
o.close() ; del o

Now you can see the memory leaks.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 20:48

Message:
Logged In: YES 
user_id=21627

Assigning to the author of the module for review. Gustavo,
if you can't find the time for a review, feel free to
unassign it.

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

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


From noreply@sourceforge.net  Fri Jan  3 20:12:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 12:12:00 -0800
Subject: [Patches] [ python-Patches-661440 ] Refactor and streamline PyCFunction_Call
Message-ID: <E18UYAi-0004EY-00@sc8-sf-web2.sourceforge.net>

Patches item #661440, was opened at 2003-01-03 04:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661440&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Martin v. Löwis (loewis)
Summary: Refactor and streamline PyCFunction_Call

Initial Comment:
Refactor PyCFunction_Call with an eye towards 
clarity and speed while leaving the semantics 
unchanged.  

It is now obvious which combinations of flags are 
allowed; the new structure makes it easier to add new 
flags and flag combinations; and every path runs 
faster (by having fewer jumps, filling variables only 
when and where needed, and by merging a test into 
the switch logic).

* Incorporated the keyword flag test into switch/case.
* Deferred initialization of "size" until when and where 
needed.
* Inverted error tests so that the common case has 
no jumps.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 21:12

Message:
Logged In: YES 
user_id=21627

I think any performance changes of this code are likely
irrelevant, for any real application. For example, it might
be that compilers can't efficiently dispatch the jump in the
new code, where they could have done so in the old code.

For gcc 3.2, the old code, for METH_O, uses four direct
jumps. The new code uses one computed and three direct
jumps, so it is slightly more expensive, in terms of jump
instructions; the function is also 40 bytes larger (313
bytes vs 357 bytes).

As I said, I cannot find one version particularly more clear
than the other - the new version could be improved by
putting the two keyword cases next to each other (something
that the old version did cleanly - you could easily tell
that keywords are processed first, and the special cases
then would not need to deal with keywords).

As for "leaving the semantics unchanged": there is a change
in semantics: METH_NOARGS|METH_KEYWORDS used to "work" (the
keyword arguments would be ignored), but gives an error
under the change. That change in semantics might be the only
reason to accept the patch, since it is now more correct.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 20:57

Message:
Logged In: YES 
user_id=31392

Sounds good to me.  The code looks clear enough.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 20:52

Message:
Logged In: YES 
user_id=80475

Okay, I improved the timing suite and found about a 5 to 
10% savings (suite attached as dict.diff and timemeth.py):

Case                NewTime        OldTime
--------                --------------         -------------
meth_o             10.60              11.53
meth_vargs      8.13                8.64
meth_noargs    8.08                8.90
meth_var&kw   8.07                8.46

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 19:47

Message:
Logged In: YES 
user_id=80475

Without making dummy C functions and C caller, I can't 
get a timing suite that isolates the improvement.  The 
timing code attached below shows no change.

>From code inspection, it's easy to see the operation count 
go down.  

For meth_o, meth_noargs and meth_oldargs, it saves the 
flags&keywords step and converts a usually-fail-jump if 
into a usually-succeed-nojump. 

For meth_vargs, it saves the size lookup, the 
flags&keywords step, saves the dict-empty test, and 
converts a usually-fail-jump if into a usually-succeed-
nojump.

For the meth_keywords case, it replaces the size lookup, 
the flags&keywords step, and a usually-succeed-no-jump if 
with a single switch/case jump.  Probably, a net wash 
here.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 18:06

Message:
Logged In: YES 
user_id=31392

Do you have any measurements of the speedup?


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 12:22

Message:
Logged In: YES 
user_id=80475

For me, the clarity comes from all allowable flag 
combinations being shown in the switch/case.

The duplication of the test for empty dictionaries and the 
computation of size are done for speed (only being done 
when and where needed).  The duplication is warranted 
only because the function is on the critical path for just 
about everything in Python and here speed really matters.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 11:40

Message:
Logged In: YES 
user_id=21627

I'm uncertain why this makes the function clearer; it
appears to make it merely different, as it duplicates the
test for empty dictionaries, and the computation of the size.



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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 11:19

Message:
Logged In: YES 
user_id=80475

Should've been assigned to Martin who wrote some of the 
existing code for that function.

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

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


From noreply@sourceforge.net  Fri Jan  3 20:43:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 12:43:13 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18UYev-0005ec-00@sc8-sf-web2.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 21:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Fri Jan  3 21:07:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 13:07:41 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18UZ2b-0006lw-00@sc8-sf-web2.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 16:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 20:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Fri Jan  3 21:16:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 13:16:27 -0800
Subject: [Patches] [ python-Patches-661869 ] gcc 3.2 /usr/local/include patch
Message-ID: <E18UZB5-0007ex-00@sc8-sf-web3.sourceforge.net>

Patches item #661869, was opened at 2003-01-03 12:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661869&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: gcc 3.2 /usr/local/include patch

Initial Comment:
The attach patch attempts to suppress error messages
like the following when building shared extensions
with gcc 3.2:

cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

Note that this patch is really a work in progress
because:

1. I'm not sure what version of gcc started to
complain about -I/usr/local/include. The only versions
that I have access to is 2.95.[23], 2.96, and 3.2.

2. There are probably better ways to implement this
patch.

Is a patch like this desired? Can you help me improve
the patch? Thanks.

[Checkbox is checked...]

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

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


From noreply@sourceforge.net  Fri Jan  3 21:17:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 13:17:10 -0800
Subject: [Patches] [ python-Patches-661869 ] gcc 3.2 /usr/local/include patch
Message-ID: <E18UZBm-0007Ca-00@sc8-sf-web2.sourceforge.net>

Patches item #661869, was opened at 2003-01-03 12:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661869&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: gcc 3.2 /usr/local/include patch

Initial Comment:
The attach patch attempts to suppress error messages
like the following when building shared extensions
with gcc 3.2:

cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

Note that this patch is really a work in progress
because:

1. I'm not sure what version of gcc started to
complain about -I/usr/local/include. The only versions
that I have access to is 2.95.[23], 2.96, and 3.2.

2. There are probably better ways to implement this
patch.

Is a patch like this desired? Can you help me improve
the patch? Thanks.

[Checkbox is checked...]

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

>Comment By: Jason Tishler (jlt63)
Date: 2003-01-03 12:17

Message:
Logged In: YES 
user_id=86216

[Checkbox is checked again...] 

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

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


From noreply@sourceforge.net  Fri Jan  3 21:20:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 13:20:45 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18UZFF-0007oW-00@sc8-sf-web3.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 16:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

>Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 20:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Fri Jan  3 23:01:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 15:01:58 -0800
Subject: [Patches] [ python-Patches-661869 ] gcc 3.2 /usr/local/include patch
Message-ID: <E18UapC-00039q-00@sc8-sf-web2.sourceforge.net>

Patches item #661869, was opened at 2003-01-03 22:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661869&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: gcc 3.2 /usr/local/include patch

Initial Comment:
The attach patch attempts to suppress error messages
like the following when building shared extensions
with gcc 3.2:

cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

Note that this patch is really a work in progress
because:

1. I'm not sure what version of gcc started to
complain about -I/usr/local/include. The only versions
that I have access to is 2.95.[23], 2.96, and 3.2.

2. There are probably better ways to implement this
patch.

Is a patch like this desired? Can you help me improve
the patch? Thanks.

[Checkbox is checked...]

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-04 00:01

Message:
Logged In: YES 
user_id=21627

I don't think we should have such a patch. If anything
should be done, we should find out what the default search
path for gcc - this is independent of the GCC version.

I really consider this a bug in gcc, and I believe that gcc
3.3 will change the behaviour, again.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-01-03 22:17

Message:
Logged In: YES 
user_id=86216

[Checkbox is checked again...] 

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

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


From noreply@sourceforge.net  Fri Jan  3 23:06:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 15:06:58 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18Uau2-0000yA-00@sc8-sf-web1.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-04 00:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 21:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Sat Jan  4 00:00:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 16:00:01 -0800
Subject: [Patches] [ python-Patches-661440 ] Refactor and streamline PyCFunction_Call
Message-ID: <E18UbjN-0003EQ-00@sc8-sf-web1.sourceforge.net>

Patches item #661440, was opened at 2003-01-02 22:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661440&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Martin v. Löwis (loewis)
Summary: Refactor and streamline PyCFunction_Call

Initial Comment:
Refactor PyCFunction_Call with an eye towards 
clarity and speed while leaving the semantics 
unchanged.  

It is now obvious which combinations of flags are 
allowed; the new structure makes it easier to add new 
flags and flag combinations; and every path runs 
faster (by having fewer jumps, filling variables only 
when and where needed, and by merging a test into 
the switch logic).

* Incorporated the keyword flag test into switch/case.
* Deferred initialization of "size" until when and where 
needed.
* Inverted error tests so that the common case has 
no jumps.



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 19:00

Message:
Logged In: YES 
user_id=80475

Are you willing to accept the patch on the basis of the 
semantic improvement?

Also, I tried the patch on a couple of my real world, 
published scripts (a matrix package and a puzzle solving 
graph traverser) and found that there was still a 
measurable though slight performance gain which isn't 
bad considering that they do a lot of work outside the 
affected code block (most optimizations affect only a 
single step and rarely give across the board significant 
speed boosts).

If you say no, that's cool.  Though I think the patch is the 
right thing to do, I'm not married to it and won't lose sleep 
if it gets rejected.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 15:12

Message:
Logged In: YES 
user_id=21627

I think any performance changes of this code are likely
irrelevant, for any real application. For example, it might
be that compilers can't efficiently dispatch the jump in the
new code, where they could have done so in the old code.

For gcc 3.2, the old code, for METH_O, uses four direct
jumps. The new code uses one computed and three direct
jumps, so it is slightly more expensive, in terms of jump
instructions; the function is also 40 bytes larger (313
bytes vs 357 bytes).

As I said, I cannot find one version particularly more clear
than the other - the new version could be improved by
putting the two keyword cases next to each other (something
that the old version did cleanly - you could easily tell
that keywords are processed first, and the special cases
then would not need to deal with keywords).

As for "leaving the semantics unchanged": there is a change
in semantics: METH_NOARGS|METH_KEYWORDS used to "work" (the
keyword arguments would be ignored), but gives an error
under the change. That change in semantics might be the only
reason to accept the patch, since it is now more correct.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 14:57

Message:
Logged In: YES 
user_id=31392

Sounds good to me.  The code looks clear enough.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 14:52

Message:
Logged In: YES 
user_id=80475

Okay, I improved the timing suite and found about a 5 to 
10% savings (suite attached as dict.diff and timemeth.py):

Case                NewTime        OldTime
--------                --------------         -------------
meth_o             10.60              11.53
meth_vargs      8.13                8.64
meth_noargs    8.08                8.90
meth_var&kw   8.07                8.46

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 13:47

Message:
Logged In: YES 
user_id=80475

Without making dummy C functions and C caller, I can't 
get a timing suite that isolates the improvement.  The 
timing code attached below shows no change.

>From code inspection, it's easy to see the operation count 
go down.  

For meth_o, meth_noargs and meth_oldargs, it saves the 
flags&keywords step and converts a usually-fail-jump if 
into a usually-succeed-nojump. 

For meth_vargs, it saves the size lookup, the 
flags&keywords step, saves the dict-empty test, and 
converts a usually-fail-jump if into a usually-succeed-
nojump.

For the meth_keywords case, it replaces the size lookup, 
the flags&keywords step, and a usually-succeed-no-jump if 
with a single switch/case jump.  Probably, a net wash 
here.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 12:06

Message:
Logged In: YES 
user_id=31392

Do you have any measurements of the speedup?


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 06:22

Message:
Logged In: YES 
user_id=80475

For me, the clarity comes from all allowable flag 
combinations being shown in the switch/case.

The duplication of the test for empty dictionaries and the 
computation of size are done for speed (only being done 
when and where needed).  The duplication is warranted 
only because the function is on the critical path for just 
about everything in Python and here speed really matters.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 05:40

Message:
Logged In: YES 
user_id=21627

I'm uncertain why this makes the function clearer; it
appears to make it merely different, as it duplicates the
test for empty dictionaries, and the computation of the size.



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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 05:19

Message:
Logged In: YES 
user_id=80475

Should've been assigned to Martin who wrote some of the 
existing code for that function.

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

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


From noreply@sourceforge.net  Sat Jan  4 00:19:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 16:19:16 -0800
Subject: [Patches] [ python-Patches-661440 ] Refactor and streamline PyCFunction_Call
Message-ID: <E18Uc20-0005dk-00@sc8-sf-web2.sourceforge.net>

Patches item #661440, was opened at 2003-01-03 04:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661440&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Refactor and streamline PyCFunction_Call

Initial Comment:
Refactor PyCFunction_Call with an eye towards 
clarity and speed while leaving the semantics 
unchanged.  

It is now obvious which combinations of flags are 
allowed; the new structure makes it easier to add new 
flags and flag combinations; and every path runs 
faster (by having fewer jumps, filling variables only 
when and where needed, and by merging a test into 
the switch logic).

* Incorporated the keyword flag test into switch/case.
* Deferred initialization of "size" until when and where 
needed.
* Inverted error tests so that the common case has 
no jumps.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-04 01:19

Message:
Logged In: YES 
user_id=21627

Since Jeremy is in favour, and I'm not strongly opposed,
please consider this patch accepted. I'm primary opposed
because of the principle "never change a running system", to
which I'm not married, either :-)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-04 01:00

Message:
Logged In: YES 
user_id=80475

Are you willing to accept the patch on the basis of the 
semantic improvement?

Also, I tried the patch on a couple of my real world, 
published scripts (a matrix package and a puzzle solving 
graph traverser) and found that there was still a 
measurable though slight performance gain which isn't 
bad considering that they do a lot of work outside the 
affected code block (most optimizations affect only a 
single step and rarely give across the board significant 
speed boosts).

If you say no, that's cool.  Though I think the patch is the 
right thing to do, I'm not married to it and won't lose sleep 
if it gets rejected.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 21:12

Message:
Logged In: YES 
user_id=21627

I think any performance changes of this code are likely
irrelevant, for any real application. For example, it might
be that compilers can't efficiently dispatch the jump in the
new code, where they could have done so in the old code.

For gcc 3.2, the old code, for METH_O, uses four direct
jumps. The new code uses one computed and three direct
jumps, so it is slightly more expensive, in terms of jump
instructions; the function is also 40 bytes larger (313
bytes vs 357 bytes).

As I said, I cannot find one version particularly more clear
than the other - the new version could be improved by
putting the two keyword cases next to each other (something
that the old version did cleanly - you could easily tell
that keywords are processed first, and the special cases
then would not need to deal with keywords).

As for "leaving the semantics unchanged": there is a change
in semantics: METH_NOARGS|METH_KEYWORDS used to "work" (the
keyword arguments would be ignored), but gives an error
under the change. That change in semantics might be the only
reason to accept the patch, since it is now more correct.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 20:57

Message:
Logged In: YES 
user_id=31392

Sounds good to me.  The code looks clear enough.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 20:52

Message:
Logged In: YES 
user_id=80475

Okay, I improved the timing suite and found about a 5 to 
10% savings (suite attached as dict.diff and timemeth.py):

Case                NewTime        OldTime
--------                --------------         -------------
meth_o             10.60              11.53
meth_vargs      8.13                8.64
meth_noargs    8.08                8.90
meth_var&kw   8.07                8.46

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 19:47

Message:
Logged In: YES 
user_id=80475

Without making dummy C functions and C caller, I can't 
get a timing suite that isolates the improvement.  The 
timing code attached below shows no change.

>From code inspection, it's easy to see the operation count 
go down.  

For meth_o, meth_noargs and meth_oldargs, it saves the 
flags&keywords step and converts a usually-fail-jump if 
into a usually-succeed-nojump. 

For meth_vargs, it saves the size lookup, the 
flags&keywords step, saves the dict-empty test, and 
converts a usually-fail-jump if into a usually-succeed-
nojump.

For the meth_keywords case, it replaces the size lookup, 
the flags&keywords step, and a usually-succeed-no-jump if 
with a single switch/case jump.  Probably, a net wash 
here.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 18:06

Message:
Logged In: YES 
user_id=31392

Do you have any measurements of the speedup?


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 12:22

Message:
Logged In: YES 
user_id=80475

For me, the clarity comes from all allowable flag 
combinations being shown in the switch/case.

The duplication of the test for empty dictionaries and the 
computation of size are done for speed (only being done 
when and where needed).  The duplication is warranted 
only because the function is on the critical path for just 
about everything in Python and here speed really matters.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 11:40

Message:
Logged In: YES 
user_id=21627

I'm uncertain why this makes the function clearer; it
appears to make it merely different, as it duplicates the
test for empty dictionaries, and the computation of the size.



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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 11:19

Message:
Logged In: YES 
user_id=80475

Should've been assigned to Martin who wrote some of the 
existing code for that function.

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

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


From noreply@sourceforge.net  Sat Jan  4 00:44:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 16:44:52 -0800
Subject: [Patches] [ python-Patches-661440 ] Refactor and streamline PyCFunction_Call
Message-ID: <E18UcQm-0007Bo-00@sc8-sf-web3.sourceforge.net>

Patches item #661440, was opened at 2003-01-02 22:06
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661440&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Refactor and streamline PyCFunction_Call

Initial Comment:
Refactor PyCFunction_Call with an eye towards 
clarity and speed while leaving the semantics 
unchanged.  

It is now obvious which combinations of flags are 
allowed; the new structure makes it easier to add new 
flags and flag combinations; and every path runs 
faster (by having fewer jumps, filling variables only 
when and where needed, and by merging a test into 
the switch logic).

* Incorporated the keyword flag test into switch/case.
* Deferred initialization of "size" until when and where 
needed.
* Inverted error tests so that the common case has 
no jumps.



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 19:44

Message:
Logged In: YES 
user_id=80475

All of which reminds me that I'm never going to get 
married if I stay at home on Friday nights working on 
Python ;)

Applied patch as methodobject.c 2.43.
Marking as closed.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 19:19

Message:
Logged In: YES 
user_id=21627

Since Jeremy is in favour, and I'm not strongly opposed,
please consider this patch accepted. I'm primary opposed
because of the principle "never change a running system", to
which I'm not married, either :-)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 19:00

Message:
Logged In: YES 
user_id=80475

Are you willing to accept the patch on the basis of the 
semantic improvement?

Also, I tried the patch on a couple of my real world, 
published scripts (a matrix package and a puzzle solving 
graph traverser) and found that there was still a 
measurable though slight performance gain which isn't 
bad considering that they do a lot of work outside the 
affected code block (most optimizations affect only a 
single step and rarely give across the board significant 
speed boosts).

If you say no, that's cool.  Though I think the patch is the 
right thing to do, I'm not married to it and won't lose sleep 
if it gets rejected.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 15:12

Message:
Logged In: YES 
user_id=21627

I think any performance changes of this code are likely
irrelevant, for any real application. For example, it might
be that compilers can't efficiently dispatch the jump in the
new code, where they could have done so in the old code.

For gcc 3.2, the old code, for METH_O, uses four direct
jumps. The new code uses one computed and three direct
jumps, so it is slightly more expensive, in terms of jump
instructions; the function is also 40 bytes larger (313
bytes vs 357 bytes).

As I said, I cannot find one version particularly more clear
than the other - the new version could be improved by
putting the two keyword cases next to each other (something
that the old version did cleanly - you could easily tell
that keywords are processed first, and the special cases
then would not need to deal with keywords).

As for "leaving the semantics unchanged": there is a change
in semantics: METH_NOARGS|METH_KEYWORDS used to "work" (the
keyword arguments would be ignored), but gives an error
under the change. That change in semantics might be the only
reason to accept the patch, since it is now more correct.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 14:57

Message:
Logged In: YES 
user_id=31392

Sounds good to me.  The code looks clear enough.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 14:52

Message:
Logged In: YES 
user_id=80475

Okay, I improved the timing suite and found about a 5 to 
10% savings (suite attached as dict.diff and timemeth.py):

Case                NewTime        OldTime
--------                --------------         -------------
meth_o             10.60              11.53
meth_vargs      8.13                8.64
meth_noargs    8.08                8.90
meth_var&kw   8.07                8.46

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 13:47

Message:
Logged In: YES 
user_id=80475

Without making dummy C functions and C caller, I can't 
get a timing suite that isolates the improvement.  The 
timing code attached below shows no change.

>From code inspection, it's easy to see the operation count 
go down.  

For meth_o, meth_noargs and meth_oldargs, it saves the 
flags&keywords step and converts a usually-fail-jump if 
into a usually-succeed-nojump. 

For meth_vargs, it saves the size lookup, the 
flags&keywords step, saves the dict-empty test, and 
converts a usually-fail-jump if into a usually-succeed-
nojump.

For the meth_keywords case, it replaces the size lookup, 
the flags&keywords step, and a usually-succeed-no-jump if 
with a single switch/case jump.  Probably, a net wash 
here.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-03 12:06

Message:
Logged In: YES 
user_id=31392

Do you have any measurements of the speedup?


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 06:22

Message:
Logged In: YES 
user_id=80475

For me, the clarity comes from all allowable flag 
combinations being shown in the switch/case.

The duplication of the test for empty dictionaries and the 
computation of size are done for speed (only being done 
when and where needed).  The duplication is warranted 
only because the function is on the critical path for just 
about everything in Python and here speed really matters.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 05:40

Message:
Logged In: YES 
user_id=21627

I'm uncertain why this makes the function clearer; it
appears to make it merely different, as it duplicates the
test for empty dictionaries, and the computation of the size.



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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-03 05:19

Message:
Logged In: YES 
user_id=80475

Should've been assigned to Martin who wrote some of the 
existing code for that function.

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

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


From noreply@sourceforge.net  Sat Jan  4 03:31:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 03 Jan 2003 19:31:37 -0800
Subject: [Patches] [ python-Patches-658599 ] Fix for bug 494589
Message-ID: <E18Uf29-00033S-00@sc8-sf-web2.sourceforge.net>

Patches item #658599, was opened at 2002-12-26 02:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
>Assigned to: Tim Peters (tim_one)
Summary: Fix for bug 494589

Initial Comment:
This is a fix for bug 494589 (os.path.expandvars)
I suggest using the same code in ntpath and posixpath.
(Maybe have a commonpath.py and let both import it?)

Python version 2.2.2
OS: NT4 SP6 (checked on NT and cygwin)

Miki

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-03 22:31

Message:
Logged In: YES 
user_id=33168

The patch didn't apply for me, so I created a new one and
attached it.  I can't test this.  Maybe Tim is interested.

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

Comment By: Miki Tebeka (tebeka)
Date: 2002-12-29 02:28

Message:
Logged In: YES 
user_id=358087

This time the checkbox is checked. :-)

Miki

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-26 13:07

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Sat Jan  4 08:30:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 04 Jan 2003 00:30:36 -0800
Subject: [Patches] [ python-Patches-662053 ] bug 661354 fix; _strptime handle OS9's lack of timezone info
Message-ID: <E18UjhU-0001Rk-00@sc8-sf-web2.sourceforge.net>

Patches item #662053, was opened at 2003-01-04 00:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662053&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug 661354 fix; _strptime handle OS9's lack of timezone info

Initial Comment:
This is a fix for bug #661354.

Patches _strptime.py so as to deal with the possibility
of timezone = ('',''), as is the case on MacOS 9.  It
is general enough, though, to also work for the
previous issue of Swedish having no concept of Am/PM
any other possible problem where a locale lacks total
info about something.

Two tests for test_strptime.py were also added.

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

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


From noreply@sourceforge.net  Sat Jan  4 15:20:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 04 Jan 2003 07:20:25 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18Uq65-0006ML-00@sc8-sf-web4.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 16:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

>Comment By: Gyro Funch (siva1311)
Date: 2003-01-04 15:20

Message:
Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 23:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 20:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Sun Jan  5 01:54:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 04 Jan 2003 17:54:29 -0800
Subject: [Patches] [ python-Patches-662433 ] Add array_contains() to arraymodule
Message-ID: <E18Uzzh-0006Tn-00@sc8-sf-web2.sourceforge.net>

Patches item #662433, was opened at 2003-01-04 20:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662433&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add array_contains() to arraymodule

Initial Comment:
Small speedup no change in API.

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

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


From noreply@sourceforge.net  Sun Jan  5 02:43:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 04 Jan 2003 18:43:57 -0800
Subject: [Patches] [ python-Patches-662433 ] Add array_contains() to arraymodule
Message-ID: <E18V0lZ-00026m-00@sc8-sf-web3.sourceforge.net>

Patches item #662433, was opened at 2003-01-04 17:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662433&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add array_contains() to arraymodule

Initial Comment:
Small speedup no change in API.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-01-04 18:43

Message:
Logged In: YES 
user_id=357491

Code looks sound to me.  The  only thing I think it is
missing is tests for the testing suite.

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

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


From noreply@sourceforge.net  Sun Jan  5 02:56:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 04 Jan 2003 18:56:24 -0800
Subject: [Patches] [ python-Patches-661760 ] Cygwin auto-import module patch
Message-ID: <E18V0xc-0008LP-00@sc8-sf-web2.sourceforge.net>

Patches item #661760, was opened at 2003-01-03 09:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661760&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: Cygwin auto-import module patch

Initial Comment:
The attached patch enables shared extension
modules to build cleanly under Cygwin without
moving the static initialization of certain function
pointers (i.e., ones exported from the Python
DLL core) to a module initialization function.

Additionally, this patch fixes the modules that
have been changed in the past to accommodate
Cygwin. Specificially, these modules are:

_hotshot.c
_randommodule.c
_tkinter.c
arraymodule.c
bz2module.c
cPickle.c
socketmodule.c

Note that contrary to my recent email to
python-dev, I did *not* make the following
changes:

$ grep '\.tp_.*[ \t]*=' *.c
bz2module.c:    BZ2File_Type.tp_base = &PyFile_Type;
bz2module.c:    BZ2File_Type.tp_new = 
PyFile_Type.tp_new;
posixmodule.c:  StatResultType.tp_new = 
statresult_new;
threadmodule.c: Locktype.tp_doc = lock_doc;
xxsubtype.c:    spamdict_type.tp_base = &PyDict_Type;
xxsubtype.c:    spamlist_type.tp_base = &PyList_Type;


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

>Comment By: Jason Tishler (jlt63)
Date: 2003-01-04 17:56

Message:
Logged In: YES 
user_id=86216

>I'm probably missing some magic here: 

Did you miss the following?

http://mail.python.org/pipermail/python-dev/2003-
January/031703.html

> shouldn't there be a patch to configure.in also
> to provide the necessary linker options?

No, the defaults are sufficient.

Please (re)read the above URL. Let me know if
you need further clarification.

The bottom line is that the patch works correctly
under Cygwin. And, AFAICT, will not break any
other platform.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 10:46

Message:
Logged In: YES 
user_id=21627

I'm probably missing some magic here: shouldn't there be a
patch to configure.in also to provide the necessary linker
options?

As for the SF breakage: you should file a bug for SF, in the
"alexandria" project. Perhaps better use a support request,
since that gets better attention.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-01-03 09:15

Message:
Logged In: YES 
user_id=86216

AFAICT, SF is still broken! I *did* check the upload
checkbox!

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

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


From noreply@sourceforge.net  Sun Jan  5 03:07:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 04 Jan 2003 19:07:10 -0800
Subject: [Patches] [ python-Patches-662454 ] (Bug 660811: importing x.y.z as m is possible, docs say othe
Message-ID: <E18V182-0000CW-00@sc8-sf-web2.sourceforge.net>

Patches item #662454, was opened at 2003-01-04 22:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662454&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Nobody/Anonymous (nobody)
Summary: (Bug 660811: importing x.y.z as m is possible, docs say othe

Initial Comment:
import os.path as o works in: 2.2.x, and 2.1.x. 
It does not work in 1.5.2 because the "as" keyword did
not exist.

Perhaps this is a left-over from docs from the 1.5 era?

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

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


From noreply@sourceforge.net  Sun Jan  5 04:10:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 04 Jan 2003 20:10:50 -0800
Subject: [Patches] [ python-Patches-662464 ] 659188: no docs for HTMLParser
Message-ID: <E18V27e-0001tk-00@sc8-sf-web2.sourceforge.net>

Patches item #662464, was opened at 2003-01-04 23:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662464&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Nobody/Anonymous (nobody)
Summary: 659188: no docs for HTMLParser

Initial Comment:
Added some high level docs to explain how to use the class.
Provided docstrings for the handle_* callback methods.

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

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


From noreply@sourceforge.net  Sun Jan  5 04:41:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 04 Jan 2003 20:41:38 -0800
Subject: [Patches] [ python-Patches-662475 ] 642391: tempfile.mktemp() docs to include dir info
Message-ID: <E18V2bS-0004zN-00@sc8-sf-web3.sourceforge.net>

Patches item #662475, was opened at 2003-01-04 23:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662475&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Nobody/Anonymous (nobody)
Summary: 642391: tempfile.mktemp() docs to include dir info

Initial Comment:
added text that states that if a directory is not
provided to mktemp(), the system wide temporary
directory, or a suitable unique directory name is
prepended to the filename

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

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


From noreply@sourceforge.net  Sun Jan  5 09:53:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 05 Jan 2003 01:53:57 -0800
Subject: [Patches] [ python-Patches-661760 ] Cygwin auto-import module patch
Message-ID: <E18V7Th-0000eo-00@sc8-sf-web2.sourceforge.net>

Patches item #661760, was opened at 2003-01-03 19:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661760&group_id=5470

Category: Modules
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Jason Tishler (jlt63)
>Assigned to: Jason Tishler (jlt63)
Summary: Cygwin auto-import module patch

Initial Comment:
The attached patch enables shared extension
modules to build cleanly under Cygwin without
moving the static initialization of certain function
pointers (i.e., ones exported from the Python
DLL core) to a module initialization function.

Additionally, this patch fixes the modules that
have been changed in the past to accommodate
Cygwin. Specificially, these modules are:

_hotshot.c
_randommodule.c
_tkinter.c
arraymodule.c
bz2module.c
cPickle.c
socketmodule.c

Note that contrary to my recent email to
python-dev, I did *not* make the following
changes:

$ grep '\.tp_.*[ \t]*=' *.c
bz2module.c:    BZ2File_Type.tp_base = &PyFile_Type;
bz2module.c:    BZ2File_Type.tp_new = 
PyFile_Type.tp_new;
posixmodule.c:  StatResultType.tp_new = 
statresult_new;
threadmodule.c: Locktype.tp_doc = lock_doc;
xxsubtype.c:    spamdict_type.tp_base = &PyDict_Type;
xxsubtype.c:    spamlist_type.tp_base = &PyList_Type;


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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-05 10:53

Message:
Logged In: YES 
user_id=21627

I had missed the fact that --enable-auto-import is enabled
by default. So the patch is fine, please apply it.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-01-05 03:56

Message:
Logged In: YES 
user_id=86216

>I'm probably missing some magic here: 

Did you miss the following?

http://mail.python.org/pipermail/python-dev/2003-
January/031703.html

> shouldn't there be a patch to configure.in also
> to provide the necessary linker options?

No, the defaults are sufficient.

Please (re)read the above URL. Let me know if
you need further clarification.

The bottom line is that the patch works correctly
under Cygwin. And, AFAICT, will not break any
other platform.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 20:46

Message:
Logged In: YES 
user_id=21627

I'm probably missing some magic here: shouldn't there be a
patch to configure.in also to provide the necessary linker
options?

As for the SF breakage: you should file a bug for SF, in the
"alexandria" project. Perhaps better use a support request,
since that gets better attention.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-01-03 19:15

Message:
Logged In: YES 
user_id=86216

AFAICT, SF is still broken! I *did* check the upload
checkbox!

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

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


From noreply@sourceforge.net  Sun Jan  5 15:52:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 05 Jan 2003 07:52:15 -0800
Subject: [Patches] [ python-Patches-652586 ] New import hooks + Import from Zip files
Message-ID: <E18VD4R-0004tZ-00@sc8-sf-web2.sourceforge.net>

Patches item #652586, was opened at 2002-12-12 11:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=652586&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: New import hooks + Import from Zip files

Initial Comment:
This patch implements two things:
- a new set of import hooks, modelled after iu.py
- builtin support for imports from Zip archives (a
competing implementation for PEP 273)

The new set of hooks probably need a better document
explaining them (perhaps a PEP). My motivations have
been posted to python-dev.

Here's a brief description.

Three new objects are added to the sys module:
- path_hooks
- path_importer_cache
- meta_path

sys.path_hooks is a list of callable objects that take
a string as their only argument. A hook will be called
with a sys.path or pkg.__path__ item. It should return
an "importer" object (see below), or raise ImportError
or return None if it can't deal with the path item. By
default, sys.path_hooks only contains the zipimporter
type, if the zipimport module is available.

sys.path_importer_cache is a dict that caches the
results of sys.path_hooks to avoid repeated hook lookups.

sys.meta_path is a list of importer objects that are
invoked *before* the builtin import mechanism kicks in.
This allows overriding of builtin module and frozen
module import, but the main feature is that it allows
importer objects *without* a corresponding sys.path
item (just like builtin and frozen modules).

Importer objects must conform to the following protocol:

i.find_module(fullname) -> None or an importer object
i.load_module(fullname) -> the imported module (or
raise ImportError)

The 'fullname' is always the fully qualified module
name, ie. a dotted name for a submodule.

This patch adds one more feature: a sys.path item may
*itself* be an importer object. This is convenient for
experimentation, but using it may break third-party
code that assumes sys.path contains only strings.

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-30 23:34

Message:
Logged In: YES 
user_id=92689

Checked in with several changes:
- importers on sys.path are no longer allowed
- zipimporter was reverted to properly support pkg.__path__
and archive.zip/subdir/ again, this time without caring
about the zip file extension.
- get_data() semantics adapted to latest version of PEP 302
- minor import.c tweaks from Guido

Commit details:
Include/pythonrun.h, rev. 2.57
Lib/site.py, rev. 1.47
Lib/test/test_importhooks.py, rev. 1.1
Lib/test/test_zipimport.py, rev. 1.1
Modules/Setup.dist, rev. 1.35
Modules/getpath.c, rev. 1.45
Modules/zipimport.c, rev. 1.1
PC/config.c, rev. 1.37
PC/getpathp.c, rev. 1.29
PCbuild/pythoncore.dsp, rev. 1.40
Python/import.c, rev. 2.215
Python/importdl.h, rev. 2.19
Python/pythonrun.c, rev. 2.172

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-23 23:31

Message:
Logged In: YES 
user_id=92689

Several changes/fixes.

general:
- incorporated patch from Paul Moore that adds a default zip
archive path to sys.path on Windows (it was already there on
unix). Thanks Paul!

import.c:
- matches latest version of PEP 302 (rev 1.3), regarding the
new 'path' argument of importer.find_module(fullname, path=None)

zipimporter.c
- removed the subdir feature, which allowed the path to the
zip archive to be extended with a subdirectory. PEP 273
stated this was needed for package support (and only for
that). However, with the new import hooks this is no longer
true: a path item containing the plain zip archive path can
also deal with submodules (find_module receives the full
module name after all). Therefore a pkg.__path__ from a
package loaded from a zip archive will contain the *plain*
zip archive path.
- as a consequence I could simplify and clean up lots of
things (esp. zipimporter_init: eg. it no longer needs to
check sys.path_importer_cache; yay). Getting rid of the
zipimporter.prefix attribute altogether helped a lot in
other places.
- this change additionally enabled me to get rid of the
restriction that zip paths must end in .ZIP or .zip; any
extension (or even no extension) will now work.
- implemented all the (optional) extensions of the Importer
Protocol that the latest version of PEP 302 defines.

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-19 22:29

Message:
Logged In: YES 
user_id=92689

I added the default sys.path zip file item for unix builds,
as PEP 273 prescribes. I've not done the refactoring that
the PEP 273 implementation does (I really don't see why),
but this means I can't use Jim Ahlstrom's PC/getpathp.c
patch as is. I don't develop on Windows, so I wouldn't be
able to test. Paul, do you think you can provide a minimal
patch for PC/getpathp.c that adds the right thing to the
default path? No rush.

Other changes:
- zipimporter.get_data() now raises IOError instead of
ZipImportError if the "file" wasn't found.
- removed the (dubious) mechanism that would *not* add a
None value on sys.path_importer_cache for path items that
have no hook and are not directories. Needed for the default
zip item change: if the default zipfile isn't available it
would otherwise keep trying to find a hook for it. This
change also means that if you install a hook on
sys.path_hooks and you want that hook to handle items that
are *already* on sys.path, you must clear
sys.path_importer_cache.

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-18 15:54

Message:
Logged In: YES 
user_id=92689

Std zip entry on sys.path: agreed, I've been meaning to look
at that for a while now...

Refactoring: would be nice (but needs a third item:
PathImporter), but it's quite a bit of extra work *and*
makes it harder (I think) to keep
imp.find_module/load_module compatible. I will have a closer
look, but I tend to think this is a better project for 2.4.
I currently prefer working on a PEP, if only to increase the
chance my work hasn't been a waste of time ;-)

Btw. zi.get_data() currently raises ZipImporterError if a
file is not found. IOError is probably better. Will also
consider list_dir() & list_modules(). (Hm, I really dislike
those underscores there, but I also don't want to remove
them from find/load_module...)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-18 14:31

Message:
Logged In: YES 
user_id=6380

OTOH I will certainly be able to work around the lacking
stat()ability; but I *need* to access the data.

I'm occupied with urgent Zope Corp work this week, so I
don't have time to review more of this code, alas. But I
recommend that Just incorporate the changes that Jim
Ahlstrom suggested (from Jim's patch) to allow the standard
library to be a zip archive (adding a standard zip file on
the path).

If after that you still have time and energy, I'd like the
search for builtins and for frozen modules to be turned into
meta-importers (or whatever you call them) that are placed
on the meta-importers hook list. That would be a nice
refactoring of import.c!

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-18 10:47

Message:
Logged In: YES 
user_id=92689

I *totally* agree that get_data() should be an optional part
of the protocol. I consider it an experimental addition
right now.

Quick thoughts:
__importer__ should be set to the object with the
load_module() method.
Yes, load_module() is responsible for setting it. It has to
be, as it is load_module() that actually runs the code, and
__import__ must be available to the running code.

PEP: Yes. I started on it last night, doing some work on it
as we speak.

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

Comment By: Paul Moore (pmoore)
Date: 2002-12-18 10:26

Message:
Logged In: YES 
user_id=113328

Be aware that this doesn't solve all of the issues (although it 
does solve a large class of them). Some applications require 
a real filename (wxPython did until recently for image data) 
and some need to stat the file (Guido quoted Zope).

At the very least it should be made clear that this is an 
*optional* part of the interface. Application code should 
always be prepared for an importer not to support get_data (if 
only by saying it can't work from a data store managed by 
this sort of hook).

My preference is for keeping the importer interface minimal 
and clean. At the moment 2 functions (find_module and 
get_module) are all that is required - and these can be in 
separate classes. Which class should have the get_data 
method? Which class gets assigned to __importer__? Is it 
the hook's responsibility to set __importer__ (yet another 
responsibility)?

I think it's time for a PEP. Not for zipimporter, but purely for 
the import hook interface. That would be the place to argue 
such issues as I raised in the paragraph above. We need to 
remain clear on what the API requires vs what zipimporter 
does, to give writers of new hooks a decent chance.

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-17 23:28

Message:
Logged In: YES 
user_id=92689

Fresh patch.
Added zipimporter.get_data(path) method: returns the
(uncompressed) data for a file as a string.

Implemented Wiktor Sadowski's suggestion: a module loaded
with zipimport will have an __importer__ attribute, which is
set to the zipimporter instance that did the load. Possible
quirk: for a package __init__.py file, this is the
zipimporter that handles the directory containing the
package dir, so __importer__.get_data(filename) looks for
filename in that directory, not the package directory. An
__importer__ of an actual submodule *does* look in the
package directory itself.

(Btw. I did this without adding a new
PyImport_ExecCodeModuleEx2 API.)

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-16 19:41

Message:
Logged In: YES 
user_id=92689

Uploaded new patch; no code changes, but a new test script:
test_importhooks.py (uses unittest). Rewrote
test_zipimport.py to also use unittest. test_importhooks.py
contains some examples of trivial importer objects as well
as an importer wrapper for imp.find_module/imp.load_module
calls. Also contains some notes about the role and
constraints of pkg.__path__.

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-15 15:28

Message:
Logged In: YES 
user_id=92689

Uploaded a new version. Many changes, but most are fairly
small. Addressed a fairly long list of comments from Guido.

General:
- lots more comments, especially for functions.
- wrapped long lines
- site.py: doesn't check for existence in the file system at
all anymore

zipimport.c:
- fixed a really dumb bug that prevented zipimporter objects
be found in the cache; this improved performance a bit in
the presence of packages. (On my box, zipimports are now
always faster than file system imports, but the difference
is much better for uncompressed zip files.)
- removed zipimporter_new (PyType_GenericNew is all we need)
- replaced all PyMapping_* calls with PyDict_* calls
- reworked module/package finding code: now really doesn't
depend on dir entries to be present in the archive.
Basically went back to how ahlstromjc did it, which makes
much more sense to me now.
- fixed some refcount bugs
- fixed a potential buffer overrun
- reduced the number of fseek() calls somewhat (XXX there's
an unused and unfinished replacement for read_directory() in
zipimport.c that reads the entire directory into memory in
one gulp. This avoids more fseek() calls and avoids many
PyMarshal_Read* calls. Nevertheless I only managed to shave
off about 10% of dir-reading time, which I think makes it
not worth the hassle. If you think this may have more effect
on your platform: please play!)

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-14 23:12

Message:
Logged In: YES 
user_id=92689

If you install a hook on sys.path_hooks and want it to
affect sys.path items that may already have been used you'd
need to clear sys.path_importer_cache. Say if you install a
directory caching hook after site.py has been imported.
Tricky, but possibly not uncommon. But at the very least the
test script needs it <wink>.

I think it's on a similar level as sys.modules: you normally
don't need it, except when you're mucking with custom import
hooks... (I know, that's not an entirely fair comparison,
but still.)

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

Comment By: Paul Moore (pmoore)
Date: 2002-12-14 22:52

Message:
Logged In: YES 
user_id=113328

Thanks for the explanation of find_module. That sounds very 
useful.

On a separate note, why do you expose 
sys.path_importer_cache? I can't imagine any reason why 
the user would ever touch it manually (other than for 
interactive experimentation).

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-14 21:46

Message:
Logged In: YES 
user_id=92689

Btw. it would be nicer if I indeed provided an "importer"
wrapper for the builtin mechanism and simply placed it on
and invoke it through sys.meta_path. The reason I haven't
done that yet is that A) this would change import.c even
more (although it would be better factored then) and B) it
would have _some_ impact on the performance of the builtin
import mechanism, as *all* imports would then pass through
yet another Python call. But I hope to play with this a bit
later next week. It could also be a project for 2.4.

Note that this is exactly what Gordon does in iu.py, except
he goes even further: he has separate importer objects on
the metapath for builtin modules, frozen modules and file
system imports. I think that's fantastic, but it would be
more controversial as it might affect performance and might
be harder to integrate with the current imp module.

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-14 21:17

Message:
Logged In: YES 
user_id=92689

Paul, this is the reason why the find_module() method
returns an object (and I guess now is a good time to explain
this <wink>; it also answers a question from Guido he asked
in private mail). zipimporter returns self, but you don't
have to do that: you can return anything with a
load_module() method. So all state you gather during
find_module() you can simply pack in a different object and
return that. Something like this

class MyHook:
    ...
    def find_module(self, fullname):
         info = self._find_module(fullname)
         if info is None:
             return None
         return Loader(info)

class Loader:
    def __init__(self, info):
        self.info = info
    def load_module(self, fullname):
        ...load module using self.info...

A good showcase for this pattern would be a wrapper for the
builtin import mechanism: it could stuff the (file,
filename, (suffix, mode, type)) tuple that imp.find_module()
returns in a loader object, whose load_module() method would
simply call imp.load_module() with that stuff. (I think such
a wrapper is needed in import.c if we want to properly
expose the new hooks in the imp module.)

You can see the importer protocol as a further abstraction
(and OO-ification) of the current
imp.find_module()/imp.load_module() calls.

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

Comment By: Paul Moore (pmoore)
Date: 2002-12-14 20:39

Message:
Logged In: YES 
user_id=113328

I have some concerns about a design issue.

I've been playing about writing my own hooks in Python, and I 
have found that for most of my tests, the find_module method 
is simply not useful. I understand that it can be cheaper 
(sometimes a lot cheaper) to just check for the existence of a 
module than actually loading up the code, etc, etc. So in 
those cases, find_module() offers a shortcut if the module 
isn't found.

But if the module *is* found, and find_module has to do 
significant work, then all this work has to be repeated at 
load_module time. There's no mechanism for the result of 
find_module (say, a pointer to the module in a zip directory, 
or whatever) to be passed to load_module. So load_module 
has no alternative than to redo the work (short of the hook 
implementing some form of internal cache mechanism, which 
could be quite messy to do).

I don't know what the likely uses of hooks will be. So I've no 
idea if find_module will turn out in practice to be a cheap 
operation. But I can certainly imagine cases (the 
hypthetical "load a module from a URL" hook) where 
find_module could be far from cheap.

Is it possible to let find_module be optional? If the hook 
implements it, let it be used as a quick check for existence. If 
the hook doesn't implement it, just go for it - call load_module 
and be prepared for a "can't find it" response.

This probably means that more extensive changes to import.c 
will be needed.  But once we expose the design, we're going 
to be stuck with backward compatibility issues forever, so it's 
important we get it right *now*, rather than later. (Although 
having find_module mandatory initially, but made optional 
later, is probably less problematic than most other forms of 
design change...)

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-13 23:44

Message:
Logged In: YES 
user_id=92689

The previous version requires it and failed if they weren't,
the present version still requires it, but missing entries
are added in the read_directory() function (around line
542). So it's guaranteed they're there if needed.

I could have solved it differently at import time, but I
thought it be better to do slightly more work at
zipdirectory-read time so we have to do less work later. I
doubt it matters much in reality, this was just the simplest
way to solve the problem...

(I'll update the test to reflect the solution of this problem.)

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

Comment By: Paul Moore (pmoore)
Date: 2002-12-13 22:20

Message:
Logged In: YES 
user_id=113328

I'd say it's pretty much guaranteed *not* to be a good idea. I 
am fairly certain that at least some Windows zip utilities fail 
to have a separate zip entry for the directory itself.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-13 21:02

Message:
Logged In: YES 
user_id=6380

Just: it looks like your latest version *requires* that the
entries for package directories are present. Is that really
a good idea?

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

Comment By: James C. Ahlstrom (ahlstromjc)
Date: 2002-12-13 20:55

Message:
Logged In: YES 
user_id=64929

The PEP 273 addition of the standard zip archive name
/usr/local/lib/python23.zip (or Windows name) to sys.path to
support import of the Python standard lib (including
site.py) from a zip archive is missing.  That was the point
of my patch to site.py, getpath.c, getpathp.c, main.c,
pythonrun.c, and sysmodule.c.  I believe those patches can
be used with this import.c if you want the feature.

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-13 20:29

Message:
Logged In: YES 
user_id=92689

I've attached a new version that fixes a problem that Thomas
Heller noticed: package imports failed when the zip archive
didn't contain a separate entry for the package directory.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-13 18:52

Message:
Logged In: YES 
user_id=6380

Thanks -- I'm reviewing this now (if not too many
distracting email arrives :-).

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-13 00:19

Message:
Logged In: YES 
user_id=92689

Yet another new version:
- zipimport is a builtin module now; includes patches for
PC\config.c and PBbuild\pythoncore.dsp, contributed and
tested by Paul Moore.
- tweaked doc strings in zipimport.
I'll quit for today...

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-12 22:59

Message:
Logged In: YES 
user_id=92689

I've uploaded a slightly updated version: the potential zlib
recursion has been fixed (I was in fact able to trigger it);
I've added a test for it, although it's tricky to do. Also
cleaned up a few exception messages in zipimport.

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-12 20:34

Message:
Logged In: YES 
user_id=92689

I've uploaded a fresh version, with GC support added. Tested
to the extent that it doesn't crash ;-)

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-12 17:34

Message:
Logged In: YES 
user_id=92689

I didn't know, thanks! I actually did find -N but it "didn't
work" ;-)

I've attached a new patch (slightly updated as well) as one
file. Also included is Lib/test/output/test_zipimport.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-12 15:28

Message:
Logged In: YES 
user_id=33168

Just, in case you didn't know, you can do a cvs diff -N to
include new/removed files in a patch.  I think you need to
do a cvs add/remove before -N works though.

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-12 15:05

Message:
Logged In: YES 
user_id=92689

I've attached test_zipimport.py, a simple test script, to be
placed in Lib/test/.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-12 14:16

Message:
Logged In: YES 
user_id=21627

recursive imports: having foo.zip as the first thing in sys.path, 
and having a compressed zlib.py in there was indeed the 
case I was thinking of (without actually trying).

GC: It is absolutely necessary. If this is not done now, 
somebody will spend days of research five years from now, 
because somebody else thought that invoking .update on this 
files attribute was a good idea. This could be reduced to C-
level documentation if the dictionary was not exposed to 
Python.

builtin: I think it ought to be builtin. It's a small module, it 
does not rely on additional libraries, it is not maintained 
externally, and it reduces bootstrap dependencies to have it 
builtin. OTOH, zlib can't be builtin, as it relies on an 
additional library which may not always be present.

get_long: you are right; the 0xff does make the values 
positive, again. I somehow thought the result might still be 
negative.



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

Comment By: Just van Rossum (jvr)
Date: 2002-12-12 13:39

Message:
Logged In: YES 
user_id=92689

Hm, regarding gc again: zipimporter objects can only
*theoretically* be involved in cycles, and only if people
muck with the "files" attribute. As it is, the "files" dict
only contains strings (keys) and tuples (values) which
contain strings and ints. So is it really neccesary?

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-12 13:35

Message:
Logged In: YES 
user_id=92689

Martin:
- Have you actually seen a recursive import of zlib? I don't
see how it's possible to cause a stackoverflow. Hm, maybe if
someone stuffs a zlib.py in a zip archive? I'll add a guard.
- Are you really saying it *should* be a builtin module, or
was that comment supposed to start with "if"? See also
Paul's remark about zlib: if zlib remains a shared lib,
having zipimport as a builtin only helps for non-compressed
archives.
- gc: I'll give this a go (never done it before!)
- get_long() -> it's called with a signed char *, and the
buf[i] & 0xff should take care of the rest, so I'm not sure
I understand. But trust your judgement and changed it in my
working copy.

Thank you very much for the quick reply!

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

Comment By: Paul Moore (pmoore)
Date: 2002-12-12 12:23

Message:
Logged In: YES 
user_id=113328

I can provide details on how to patch the Windows build 
process - it's not hard. The question of whether to have 
zipimport as builtin or dynamic should be resolved first (the 
processes are different in the 2 cases).

It should be pointed out that if zipimport is builtin, it still relies 
on a dynamic module (zlib) for importing from compressed 
zips. I don't know whether this affects the decision, though...

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-12 12:15

Message:
Logged In: YES 
user_id=21627

Some comments:
- zipimport should normally be built as a builtin module, there
  should also be a patch for the Windows build procedure
- zipimporters need to support garbage collection, as they 
can occur in cycles
- there should be a mechanism to prevent a stack overflow in 
case of recursive import of zlib.
- get_long needs to accept an unsigned char*

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

Comment By: Just van Rossum (jvr)
Date: 2002-12-12 11:37

Message:
Logged In: YES 
user_id=92689

btw. the attached file contains a patch for various files as
well as a new file: zipimporter.c. Place the latter in the
Modules/ directory.

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

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


From noreply@sourceforge.net  Sun Jan  5 20:09:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 05 Jan 2003 12:09:47 -0800
Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory
Message-ID: <E18VH5f-0000DB-00@sc8-sf-web4.sourceforge.net>

Patches item #661796, was opened at 2003-01-03 14:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: BZ2File leaking fd and memory

Initial Comment:
The attached patch fixes BZ2File() leaking the fd and
PyFileObject* info (name, read ahead buffer) when an
object is deleted.

I'm not sure the patch fixes these problems in the best
way.  It exposes most of the implementation from
fileobject.c::file_dealloc() through a private API
_PyFile_Dealloc().
BZ2File derives from PyFileObject.

Make sure the file: 'empty' exists and do: 

  from bz2 import *

A simple test which demonstrates the problem is:

  for i in range(100000): o = BZ2File('empty') ; del o

Without the patch, you quickly get:

IOError: [Errno 24] Too many open files: 'empty'

You can modify this to:

  for i in range(100000): o = BZ2File('empty') ;
o.close() ; del o

Now you can see the memory leaks.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-05 15:09

Message:
Logged In: YES 
user_id=33168

I've found a better solution: change the last line of
BZ2File_dealloc() from: 
  ((PyObject*)self)->ob_type->tp_free((PyObject *)self);

to
  PyFile_Type.tp_dealloc((PyObject *)self);
Updated patch attached.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 14:48

Message:
Logged In: YES 
user_id=21627

Assigning to the author of the module for review. Gustavo,
if you can't find the time for a review, feel free to
unassign it.

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

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


From noreply@sourceforge.net  Sun Jan  5 20:50:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 05 Jan 2003 12:50:11 -0800
Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest
Message-ID: <E18VHil-0004ON-00@sc8-sf-web1.sourceforge.net>

Patches item #662807, was opened at 2003-01-05 21:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Port tests to unittest

Initial Comment:
This patch ports the three tests test_pow.py, 
test_charmapcodec.py and test_userdict.py to unittest.

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

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


From noreply@sourceforge.net  Sun Jan  5 20:56:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 05 Jan 2003 12:56:41 -0800
Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest
Message-ID: <E18VHp3-0004bh-00@sc8-sf-web1.sourceforge.net>

Patches item #662807, was opened at 2003-01-05 21:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Port tests to unittest

Initial Comment:
This patch ports the three tests test_pow.py, 
test_charmapcodec.py and test_userdict.py to unittest.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-05 21:56

Message:
Logged In: YES 
user_id=89016

The patch is hard to read, so I'll upload all three test scripts.

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

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


From noreply@sourceforge.net  Sun Jan  5 20:59:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 05 Jan 2003 12:59:46 -0800
Subject: [Patches] [ python-Patches-662433 ] Fill arraymodule's tp_iter and sq_contains slots
Message-ID: <E18VHs2-0008Ft-00@sc8-sf-web3.sourceforge.net>

Patches item #662433, was opened at 2003-01-04 20:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662433&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Fill arraymodule's tp_iter and sq_contains slots

Initial Comment:
Small speedup no change in API.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-05 15:59

Message:
Logged In: YES 
user_id=80475

New patch has test code and fills both the tp_iter and 
sq_contains slots.  

Matches what we've already done for listobjec, 
tupleobject, and rangeobject to improve their performance.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-01-04 21:43

Message:
Logged In: YES 
user_id=357491

Code looks sound to me.  The  only thing I think it is
missing is tests for the testing suite.

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

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


From noreply@sourceforge.net  Sun Jan  5 21:11:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 05 Jan 2003 13:11:20 -0800
Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory
Message-ID: <E18VI3E-0000KH-00@sc8-sf-web3.sourceforge.net>

Patches item #661796, was opened at 2003-01-03 14:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: BZ2File leaking fd and memory

Initial Comment:
The attached patch fixes BZ2File() leaking the fd and
PyFileObject* info (name, read ahead buffer) when an
object is deleted.

I'm not sure the patch fixes these problems in the best
way.  It exposes most of the implementation from
fileobject.c::file_dealloc() through a private API
_PyFile_Dealloc().
BZ2File derives from PyFileObject.

Make sure the file: 'empty' exists and do: 

  from bz2 import *

A simple test which demonstrates the problem is:

  for i in range(100000): o = BZ2File('empty') ; del o

Without the patch, you quickly get:

IOError: [Errno 24] Too many open files: 'empty'

You can modify this to:

  for i in range(100000): o = BZ2File('empty') ;
o.close() ; del o

Now you can see the memory leaks.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-05 16:11

Message:
Logged In: YES 
user_id=6380

Um, I don't understand why the BZ2File class inherits from
FileObject. It doesn't seem to be inheriting any code, and
there's no reason to inherit from FileObject just to make a
file-like object. Maybe it was a misunderstanding?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-05 15:09

Message:
Logged In: YES 
user_id=33168

I've found a better solution: change the last line of
BZ2File_dealloc() from: 
  ((PyObject*)self)->ob_type->tp_free((PyObject *)self);

to
  PyFile_Type.tp_dealloc((PyObject *)self);
Updated patch attached.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 14:48

Message:
Logged In: YES 
user_id=21627

Assigning to the author of the module for review. Gustavo,
if you can't find the time for a review, feel free to
unassign it.

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

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


From noreply@sourceforge.net  Sun Jan  5 21:34:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 05 Jan 2003 13:34:04 -0800
Subject: [Patches] [ python-Patches-661437 ] apply() should get PendingDeprecation
Message-ID: <E18VIPE-0007az-00@sc8-sf-web2.sourceforge.net>

Patches item #661437, was opened at 2003-01-02 21:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661437&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: apply() should get PendingDeprecation

Initial Comment:
Submitting this so I don't forget about it <wink>.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-05 16:34

Message:
Logged In: YES 
user_id=33168

You mean, like these two lines at line 72 of
Python/bltinmodule.c :-)

+       PyErr_Warn(PyExc_PendingDeprecationWarning,
+                  "use func(*args, **kwargs) instead of
apply()");

Perhaps func should be function(...).
Let me know if you want me to check that in.  I did attach a
patch too.

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

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


From noreply@sourceforge.net  Sun Jan  5 21:45:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 05 Jan 2003 13:45:27 -0800
Subject: [Patches] [ python-Patches-662053 ] bug 661354 fix; _strptime handle OS9's lack of timezone info
Message-ID: <E18VIaF-0001cl-00@sc8-sf-web3.sourceforge.net>

Patches item #662053, was opened at 2003-01-04 09:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662053&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
>Assigned to: Jack Jansen (jackjansen)
Summary: bug 661354 fix; _strptime handle OS9's lack of timezone info

Initial Comment:
This is a fix for bug #661354.

Patches _strptime.py so as to deal with the possibility
of timezone = ('',''), as is the case on MacOS 9.  It
is general enough, though, to also work for the
previous issue of Swedish having no concept of Am/PM
any other possible problem where a locale lacks total
info about something.

Two tests for test_strptime.py were also added.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2003-01-05 22:45

Message:
Logged In: YES 
user_id=45365

Brett,
thanks, that fixed my bug! I've assigned to myself, and I'll close it when I've merged the changed back onto the trunk.

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

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


From noreply@sourceforge.net  Sun Jan  5 21:57:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 05 Jan 2003 13:57:12 -0800
Subject: [Patches] [ python-Patches-662836 ] Implement FSSpec.SetDates()
Message-ID: <E18VIlc-00029a-00@sc8-sf-web3.sourceforge.net>

Patches item #662836, was opened at 2003-01-05 22:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662836&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Implement FSSpec.SetDates()

Initial Comment:
FSSpec.SetDates() is so useful that it needs to be implemented. Probably an implementation via FSRef.FSSetCatalogInfo() or one of its brethren is best, there's other useful stuff there too.

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

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


From noreply@sourceforge.net  Sun Jan  5 23:25:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 05 Jan 2003 15:25:40 -0800
Subject: [Patches] [ python-Patches-651082 ] tarfile module implementation
Message-ID: <E18VK9E-0003kO-00@sc8-sf-web2.sourceforge.net>

Patches item #651082, was opened at 2002-12-09 15:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=651082&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Lars Gustäbel (gustaebel)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: tarfile module implementation

Initial Comment:
The tarfile module provides a comprehensive interface
to tar archive files with transparent gzip and bzip2
compression. The attachment includes tarfile.py itself,
the documentation and the tests.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-05 18:25

Message:
Logged In: YES 
user_id=33168

Thanks!  Checked in as:

Misc/ACKS 1.221
Misc/NEWS 1.601

Doc/Makefile.deps 1.94
Doc/lib/lib.tex 1.210
Doc/lib/libtarfile.tex 1.1
Lib/tarfile.py 1.1
Lib/test/testtar.tar 1.1
Lib/test/test_tarfile.py 1.1

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

Comment By: Lars Gustäbel (gustaebel)
Date: 2002-12-31 09:57

Message:
Logged In: YES 
user_id=642936

Fixed missing slashes at the end of directory names in GNU
longname blocks.

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

Comment By: Lars Gustäbel (gustaebel)
Date: 2002-12-30 19:00

Message:
Logged In: YES 
user_id=642936

Fixed a bug in TarFile.proc_gnulong() that did wrong seek()s
under certain conditions.

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

Comment By: Lars Gustäbel (gustaebel)
Date: 2002-12-25 05:30

Message:
Logged In: YES 
user_id=642936

> However, I don't like that testtar.tar has to be in
> the local directory.  It would probably be better to allow
> this file to be in the Lib/test directory.

Ok, I fixed test_tarfile.py.

> Has there
> been any testing on these platforms?  In particular, make a
> tar file with symlinks, block devices, different users and
> try to unpack on win/mac.

tarfile is intended to be platform independent. It is known to
work on Unix (Linux, FreeBSD, HP-UX) and Windows. Special files
(like links, fifos and devices) are extracted depending on which
functions are present in the os module.  On Windows for example
where there are no os.symlink() and os.link() functions, links
are extracted as copies of the files they're pointing at. Device
files are simply not extracted and a warning is shown.
I've no experiences on how things work on MacOS, but I suppose
that it is similar to Windows (no links, no special devices
etc.). I've never had complaints from Mac users in the past, so
I guess everything works fine ;-)

> I noticed sometimes you raise an exception when self.closed,
> other times just return.  Do you need the self.closed flag?
> Could you use the underlying file-objects behaviour, ie,
> assume that the file is open?

self.closed is used for write-mode. A valid tar archive must end
with two zero blocks. So, if TarFile.close() is called, these
two blocks are written out and access to the TarFile is
disallowed. I didn't want to use the status of the underlying
file-object for this because the user her/himself should decide
when he wants to close it, perhaps he wants to append more data
to it after closing the TarFile. However, this applies to the
case when a user passes her/his own file-object to the TarFile
constructor. If TarFile itself creates a file-object, it is
closed when TarFile.close() is called.

> Does the normpath/lambda code work on the mac/windows?

Pathnames in tar archives should contain forward slashes as
separators.  The module-level normpath() is used on platforms
that have a different path separator to convert pathnames when
they're added.

> In ExFileObject._readsparse(), is the loop likely to be
> executed much?  If there is a performance concern here,
> suggest you use a list.

Good point.

> What does TarFile.list() print, rather than return a list of
> strings or something else?

TarFile.list() is a bit of a rudiment from the times when
tarfile.py was compatible to zipfile.py. It prints out a verbose
list output similar to 'tar -tv'. I think it is also a good
example on how to deal with information from TarInfo objects. To
get a list of archive members use TarFile.getmembers().

> Should TarFile._extract_member() use normpath() instead of
> os.path.normpath()?

As stated above, no. normpath is only used for addition of
files.

> os.makenod() & os.makedev() are not guaranteed to exist. 
> Should there be a try/except AttributeError in
> TarFile.makedev()?
> Same comment applies to os.geteuid() in chown.

In tarfile.py, I checked for os.mknod() and assumed that if
os.mknod() is
present, os.makedev() is present, too. However, I changed this
now to be a bit more explicit.
Same in chown(), I checked for pwd and, if present, assumed that
os.geteuid() is there too. I made this more explicit, too.

> Do the pwd and grp modules work on windows/mac?

Not AFAIK.

> Now on to the pychecker warnings :-)
>
> Lib/tarfile.py:950: Parameter (compresslevel) not used

This was indeed a bug :-(

> Lib/tarfile.py:1409: Parameter (tarinfo) not used
> Lib/tarfile.py:1435: Parameter (tarinfo) not used

Both ok. They could be used, when the methods are overloaded in
a subclass.

> Lib/tarfile.py:1878: Module (time) re-imported

fixed.

> Lib/tarfile.py:1898: Parameter (compress_type) not used

This is there for compatibility to the zipfile module's API.

> One additional note, Guido asked on python-dev on Dec 12:
>
>   Is there any chance that this can be contributed to the
>   PSF under the standard PSF license?
>
> I don't remember seeing an answer.

Maybe I could have stated this more clearly but I agreed to
using the PSF license. I sent the letter of agreement to the
PSF a week ago, it should soon arrive there.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-22 19:24

Message:
Logged In: YES 
user_id=33168

One additional note, Guido asked on python-dev on Dec 12:

  Is there any chance that this can be contributed to the
PSF under the standard PSF license?

I don't remember seeing an answer.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-22 19:14

Message:
Logged In: YES 
user_id=33168

The code looks pretty good.  I ran the test on Linux and it
passed.  However, I don't like that testtar.tar has to be in
the local directory.  It would probably be better to allow
this file to be in the Lib/test directory.

I think this would be a good addition to the stdlib.  My
biggest concern is portability issues to win/mac.  Has there
been any testing on these platforms?  In particular, make a
tar file with symlinks, block devices, different users and
try to unpack on win/mac.

In TarFile.open(), where you do:
      filemode, comptype = mode.split(":")
You should add 1 to the call to split:
      filemode, comptype = mode.split(":", 1)

Same deal further down when splitting on '|'

I noticed sometimes you raise an exception when self.closed,
other times just return.  Do you need the self.closed flag?
 Could you use the underlying file-objects behaviour, ie,
assume that the file is open?

Does the normpath/lambda code work on the mac/windows?

In ExFileObject._readsparse(), is the loop likely to be
executed much?  If there is a performance concern here,
suggest you use a list.  Then outside the loop, do a data =
''.join(list) ; size -= len(data).  (You could move the size
-= len(buf) outside the loop, if you get the len(data).)

What does TarFile.list() print, rather than return a list of
strings or something else?

Should TarFile._extract_member() use normpath() instead of
os.path.normpath()?

os.makenod() & os.makedev() are not guaranteed to exist. 
Should there be a try/except AttributeError in
TarFile.makedev()?
Same comment applies to os.geteuid() in chown.

Do the pwd and grp modules work on windows/mac?

Now on to the pychecker warnings :-)

Lib/tarfile.py:950: Parameter (compresslevel) not used
Lib/tarfile.py:1409: Parameter (tarinfo) not used
Lib/tarfile.py:1435: Parameter (tarinfo) not used
Lib/tarfile.py:1878: Module (time) re-imported
Lib/tarfile.py:1898: Parameter (compress_type) not used

The last one Paramter (compress_type) not used may be ok,
not sure about others.

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

Comment By: Lars Gustäbel (gustaebel)
Date: 2002-12-17 09:41

Message:
Logged In: YES 
user_id=642936

I had to fix a small bug in TarFile.bz2open.

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

Comment By: Lars Gustäbel (gustaebel)
Date: 2002-12-09 15:54

Message:
Logged In: YES 
user_id=642936

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Mon Jan  6 08:31:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 00:31:07 -0800
Subject: [Patches] [ python-Patches-662433 ] Fill arraymodule's tp_iter and sq_contains slots
Message-ID: <E18VSf5-0001Er-00@sc8-sf-web1.sourceforge.net>

Patches item #662433, was opened at 2003-01-04 20:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662433&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Fill arraymodule's tp_iter and sq_contains slots

Initial Comment:
Small speedup no change in API.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-05 15:59

Message:
Logged In: YES 
user_id=80475

New patch has test code and fills both the tp_iter and 
sq_contains slots.  

Matches what we've already done for listobjec, 
tupleobject, and rangeobject to improve their performance.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-01-04 21:43

Message:
Logged In: YES 
user_id=357491

Code looks sound to me.  The  only thing I think it is
missing is tests for the testing suite.

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

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


From noreply@sourceforge.net  Mon Jan  6 16:53:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 08:53:52 -0800
Subject: [Patches] [ python-Patches-642236 ] optparse LaTeX docs (bug #638703)
Message-ID: <E18VaVc-0004pQ-00@sc8-sf-web1.sourceforge.net>

Patches item #642236, was opened at 2002-11-22 06:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=642236&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Neal Norwitz (nnorwitz)
Summary: optparse LaTeX docs (bug #638703)

Initial Comment:
As said in my comment on bug #638703, I've made 
some LaTeX documentation based on the text files from 
the standalone Optik package. Contrary to my comment 
there, I haven't added reference documentation based on 
pydoc.help(optparse). I'm not convinced this would add 
any value to the documentation.

An archive is attached with:

- liboptparse.tex
- patch for lib.tex
- patch for Makefile.deps

And three example files, used in liboptparse.tex (with 
\verbatiminput)
- required_1.py
- required_2.py
- caseless.py

The diffs are based on 14/11 CVS, because my 
workstation isn't on the internet. I have to mirror Python 
CVS using a CD-RW from another computer.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-06 11:53

Message:
Logged In: YES 
user_id=33168

Thanks!

Checked in as:
 Doc/Makefile.deps 1.96
 Doc/lib/lib.tex 1.212
 Doc/lib/liboptparse.tex 1.1
 Doc/lib/caseless.py 1.1
 Doc/lib/require_1.py 1.1 Doc/lib/require_2.py 1.1



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-06 10:40

Message:
Logged In: YES 
user_id=3066

Neal, please go ahead with this; thanks!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-01 17:48

Message:
Logged In: YES 
user_id=33168

Updated attachment to have everything in one patch file.

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

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


From noreply@sourceforge.net  Mon Jan  6 12:46:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 04:46:18 -0800
Subject: [Patches] [ python-Patches-661760 ] Cygwin auto-import module patch
Message-ID: <E18VWe2-0004iK-00@sc8-sf-web4.sourceforge.net>

Patches item #661760, was opened at 2003-01-03 09:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661760&group_id=5470

Category: Modules
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Jason Tishler (jlt63)
Summary: Cygwin auto-import module patch

Initial Comment:
The attached patch enables shared extension
modules to build cleanly under Cygwin without
moving the static initialization of certain function
pointers (i.e., ones exported from the Python
DLL core) to a module initialization function.

Additionally, this patch fixes the modules that
have been changed in the past to accommodate
Cygwin. Specificially, these modules are:

_hotshot.c
_randommodule.c
_tkinter.c
arraymodule.c
bz2module.c
cPickle.c
socketmodule.c

Note that contrary to my recent email to
python-dev, I did *not* make the following
changes:

$ grep '\.tp_.*[ \t]*=' *.c
bz2module.c:    BZ2File_Type.tp_base = &PyFile_Type;
bz2module.c:    BZ2File_Type.tp_new = 
PyFile_Type.tp_new;
posixmodule.c:  StatResultType.tp_new = 
statresult_new;
threadmodule.c: Locktype.tp_doc = lock_doc;
xxsubtype.c:    spamdict_type.tp_base = &PyDict_Type;
xxsubtype.c:    spamlist_type.tp_base = &PyList_Type;


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

>Comment By: Jason Tishler (jlt63)
Date: 2003-01-06 03:46

Message:
Logged In: YES 
user_id=86216

Checked in as:

Include/pyport.h 2.58
Modules/_hotshot.c 1.32
Modules/_randommodule.c 1.3
Modules/_tkinter.c 1.146
Modules/arraymodule.c 2.81
Modules/bz2module.c 1.14
Modules/cPickle.c 2.99
Modules/socketmodule.c 1.251

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-05 00:53

Message:
Logged In: YES 
user_id=21627

I had missed the fact that --enable-auto-import is enabled
by default. So the patch is fine, please apply it.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-01-04 17:56

Message:
Logged In: YES 
user_id=86216

>I'm probably missing some magic here: 

Did you miss the following?

http://mail.python.org/pipermail/python-dev/2003-
January/031703.html

> shouldn't there be a patch to configure.in also
> to provide the necessary linker options?

No, the defaults are sufficient.

Please (re)read the above URL. Let me know if
you need further clarification.

The bottom line is that the patch works correctly
under Cygwin. And, AFAICT, will not break any
other platform.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 10:46

Message:
Logged In: YES 
user_id=21627

I'm probably missing some magic here: shouldn't there be a
patch to configure.in also to provide the necessary linker
options?

As for the SF breakage: you should file a bug for SF, in the
"alexandria" project. Perhaps better use a support request,
since that gets better attention.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-01-03 09:15

Message:
Logged In: YES 
user_id=86216

AFAICT, SF is still broken! I *did* check the upload
checkbox!

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

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


From noreply@sourceforge.net  Mon Jan  6 12:50:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 04:50:44 -0800
Subject: [Patches] [ python-Patches-661869 ] gcc 3.2 /usr/local/include patch
Message-ID: <E18VWiK-0004pY-00@sc8-sf-web4.sourceforge.net>

Patches item #661869, was opened at 2003-01-03 12:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661869&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: gcc 3.2 /usr/local/include patch

Initial Comment:
The attach patch attempts to suppress error messages
like the following when building shared extensions
with gcc 3.2:

cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

Note that this patch is really a work in progress
because:

1. I'm not sure what version of gcc started to
complain about -I/usr/local/include. The only versions
that I have access to is 2.95.[23], 2.96, and 3.2.

2. There are probably better ways to implement this
patch.

Is a patch like this desired? Can you help me improve
the patch? Thanks.

[Checkbox is checked...]

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

>Comment By: Jason Tishler (jlt63)
Date: 2003-01-06 03:50

Message:
Logged In: YES 
user_id=86216

OK, I don't feel strongly enough to pursue this one.

Please feel free to close this patch.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 14:01

Message:
Logged In: YES 
user_id=21627

I don't think we should have such a patch. If anything
should be done, we should find out what the default search
path for gcc - this is independent of the GCC version.

I really consider this a bug in gcc, and I believe that gcc
3.3 will change the behaviour, again.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-01-03 12:17

Message:
Logged In: YES 
user_id=86216

[Checkbox is checked again...] 

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

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


From noreply@sourceforge.net  Mon Jan  6 12:56:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 04:56:19 -0800
Subject: [Patches] [ python-Patches-661869 ] gcc 3.2 /usr/local/include patch
Message-ID: <E18VWnj-0004vn-00@sc8-sf-web4.sourceforge.net>

Patches item #661869, was opened at 2003-01-03 22:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661869&group_id=5470

Category: Distutils and setup.py
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: gcc 3.2 /usr/local/include patch

Initial Comment:
The attach patch attempts to suppress error messages
like the following when building shared extensions
with gcc 3.2:

cc1: warning: changing search order for system 
directory "/usr/local/include"
cc1: warning:   as it has already been specified as a non-
system directory

Note that this patch is really a work in progress
because:

1. I'm not sure what version of gcc started to
complain about -I/usr/local/include. The only versions
that I have access to is 2.95.[23], 2.96, and 3.2.

2. There are probably better ways to implement this
patch.

Is a patch like this desired? Can you help me improve
the patch? Thanks.

[Checkbox is checked...]

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

Comment By: Jason Tishler (jlt63)
Date: 2003-01-06 13:50

Message:
Logged In: YES 
user_id=86216

OK, I don't feel strongly enough to pursue this one.

Please feel free to close this patch.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-04 00:01

Message:
Logged In: YES 
user_id=21627

I don't think we should have such a patch. If anything
should be done, we should find out what the default search
path for gcc - this is independent of the GCC version.

I really consider this a bug in gcc, and I believe that gcc
3.3 will change the behaviour, again.

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

Comment By: Jason Tishler (jlt63)
Date: 2003-01-03 22:17

Message:
Logged In: YES 
user_id=86216

[Checkbox is checked again...] 

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

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


From noreply@sourceforge.net  Mon Jan  6 13:15:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 05:15:09 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18VX5x-0006KH-00@sc8-sf-web3.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 16:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

>Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 13:15

Message:
Logged In: YES 
user_id=679947

The following patch adds a 'PyCompileError' exception to
py_compile and adds the appropriate 'except' and 'raise'
clauses to py_compile.py, compileall.py, and zipfile.py (I
think that these are the only affected files in the standard
library).
The exception class messages were chosen to try to simulate
the current behavior in these files as closely as possible.

If this patch looks okay (or at least is in the right
direction), I'll begin to look at the documentation and
migration issues.


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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-04 15:20

Message:
Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 23:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 20:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Mon Jan  6 13:27:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 05:27:46 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18VXIA-00061M-00@sc8-sf-web4.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 14:27

Message:
Logged In: YES 
user_id=21627

The patch looks fine so far, except for a few minor issues
(i.e. never to use bare except: clauses). You don't have to
implement a migration strategy: just elaborating it here
would be fine. To preserve compatibility, I could envision a
flag ('doraise' or some such), or a different entry point.
If you manage to provide full backwards compatibility, you
don't need to change any of the existing callers.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 14:15

Message:
Logged In: YES 
user_id=679947

The following patch adds a 'PyCompileError' exception to
py_compile and adds the appropriate 'except' and 'raise'
clauses to py_compile.py, compileall.py, and zipfile.py (I
think that these are the only affected files in the standard
library).
The exception class messages were chosen to try to simulate
the current behavior in these files as closely as possible.

If this patch looks okay (or at least is in the right
direction), I'll begin to look at the documentation and
migration issues.


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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-04 16:20

Message:
Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-04 00:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 21:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Mon Jan  6 14:48:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 06:48:57 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18VYYj-0007P8-00@sc8-sf-web2.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 16:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

>Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 14:48

Message:
Logged In: YES 
user_id=679947

I have implemented a 'doraise' flag in py_compile.compile.
I think the patch should now be backwards-compatible.
However, I think that files that use py_compile in the
standard library (compileall.py and zipfile.py) should
perhaps use the new exception mechanism for clarity and as a
demonstration of how to use the exception.
What do you think?
I'm not sure if I've eliminated the 'few minor issues'. I
did  implement 'except Exception:' instead of a raw
'except:'. Is this what you meant.
Thanks for your comments.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 13:27

Message:
Logged In: YES 
user_id=21627

The patch looks fine so far, except for a few minor issues
(i.e. never to use bare except: clauses). You don't have to
implement a migration strategy: just elaborating it here
would be fine. To preserve compatibility, I could envision a
flag ('doraise' or some such), or a different entry point.
If you manage to provide full backwards compatibility, you
don't need to change any of the existing callers.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 13:15

Message:
Logged In: YES 
user_id=679947

The following patch adds a 'PyCompileError' exception to
py_compile and adds the appropriate 'except' and 'raise'
clauses to py_compile.py, compileall.py, and zipfile.py (I
think that these are the only affected files in the standard
library).
The exception class messages were chosen to try to simulate
the current behavior in these files as closely as possible.

If this patch looks okay (or at least is in the right
direction), I'll begin to look at the documentation and
migration issues.


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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-04 15:20

Message:
Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 23:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 20:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Mon Jan  6 15:03:42 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 07:03:42 -0800
Subject: [Patches] [ python-Patches-662433 ] Fill arraymodule's tp_iter and sq_contains slots
Message-ID: <E18VYn0-00081D-00@sc8-sf-web1.sourceforge.net>

Patches item #662433, was opened at 2003-01-04 20:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662433&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Fill arraymodule's tp_iter and sq_contains slots

Initial Comment:
Small speedup no change in API.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-06 10:03

Message:
Logged In: YES 
user_id=6380

I have no time to review this code, but I'm +1 on doing this.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-05 15:59

Message:
Logged In: YES 
user_id=80475

New patch has test code and fills both the tp_iter and 
sq_contains slots.  

Matches what we've already done for listobjec, 
tupleobject, and rangeobject to improve their performance.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-01-04 21:43

Message:
Logged In: YES 
user_id=357491

Code looks sound to me.  The  only thing I think it is
missing is tests for the testing suite.

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

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


From noreply@sourceforge.net  Mon Jan  6 15:30:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 07:30:13 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18VZCf-0000mb-00@sc8-sf-web2.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 16:30

Message:
Logged In: YES 
user_id=21627

I'm still unsure why you replace the except SyntaxError: with 
except Exception:. What other exceptions could occur in this 
place? Also, calling exc_info isn't necessary - you could 
obtain the exception value in the catch clause. Unless you 
are expecting string exceptions (which ones), code to 
support string exceptions should not be needed, and the type 
can be obtained by looking at __class__.

Don't compare types by comparing their names: to find out 
whether t is SyntaxError, write 't is SyntaxError', 
not 't.__name__ == "SyntaxError"'.

Exception instances should always have a .args attribute. 
This is best generated by calling the base class __init__ in 
an exception's __init__.

Please provide the documentation changes (docstrings, 
Doc/lib, and a NEWS entry) as well.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 15:48

Message:
Logged In: YES 
user_id=679947

I have implemented a 'doraise' flag in py_compile.compile.
I think the patch should now be backwards-compatible.
However, I think that files that use py_compile in the
standard library (compileall.py and zipfile.py) should
perhaps use the new exception mechanism for clarity and as a
demonstration of how to use the exception.
What do you think?
I'm not sure if I've eliminated the 'few minor issues'. I
did  implement 'except Exception:' instead of a raw
'except:'. Is this what you meant.
Thanks for your comments.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 14:27

Message:
Logged In: YES 
user_id=21627

The patch looks fine so far, except for a few minor issues
(i.e. never to use bare except: clauses). You don't have to
implement a migration strategy: just elaborating it here
would be fine. To preserve compatibility, I could envision a
flag ('doraise' or some such), or a different entry point.
If you manage to provide full backwards compatibility, you
don't need to change any of the existing callers.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 14:15

Message:
Logged In: YES 
user_id=679947

The following patch adds a 'PyCompileError' exception to
py_compile and adds the appropriate 'except' and 'raise'
clauses to py_compile.py, compileall.py, and zipfile.py (I
think that these are the only affected files in the standard
library).
The exception class messages were chosen to try to simulate
the current behavior in these files as closely as possible.

If this patch looks okay (or at least is in the right
direction), I'll begin to look at the documentation and
migration issues.


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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-04 16:20

Message:
Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-04 00:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 21:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Mon Jan  6 15:40:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 07:40:27 -0800
Subject: [Patches] [ python-Patches-642236 ] optparse LaTeX docs (bug #638703)
Message-ID: <E18VZMZ-00013r-00@sc8-sf-web2.sourceforge.net>

Patches item #642236, was opened at 2002-11-22 06:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=642236&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: optparse LaTeX docs (bug #638703)

Initial Comment:
As said in my comment on bug #638703, I've made 
some LaTeX documentation based on the text files from 
the standalone Optik package. Contrary to my comment 
there, I haven't added reference documentation based on 
pydoc.help(optparse). I'm not convinced this would add 
any value to the documentation.

An archive is attached with:

- liboptparse.tex
- patch for lib.tex
- patch for Makefile.deps

And three example files, used in liboptparse.tex (with 
\verbatiminput)
- required_1.py
- required_2.py
- caseless.py

The diffs are based on 14/11 CVS, because my 
workstation isn't on the internet. I have to mirror Python 
CVS using a CD-RW from another computer.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-06 10:40

Message:
Logged In: YES 
user_id=3066

Neal, please go ahead with this; thanks!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-01 17:48

Message:
Logged In: YES 
user_id=33168

Updated attachment to have everything in one patch file.

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

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


From noreply@sourceforge.net  Mon Jan  6 22:37:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 14:37:41 -0800
Subject: [Patches] [ python-Patches-663369 ] (email) Escape backslashes in specialsre and escapesre
Message-ID: <E18VfsL-00066t-00@sc8-sf-web4.sourceforge.net>

Patches item #663369, was opened at 2003-01-06 22:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663369&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Woodcraft (mhf)
Assigned to: Nobody/Anonymous (nobody)
Summary: (email) Escape backslashes in specialsre and escapesre

Initial Comment:
(email/Utils.py) Escape backslashes in character
classes in specialsre and escapesre.

Patch against sourceforge CVS as of 2003-01-06
python/dist/src/Lib/email/Utils.py  rev 1.21
python/dist/src/Lib/email/test/test_email.py  rev 1.29


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

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


From noreply@sourceforge.net  Mon Jan  6 22:39:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 14:39:33 -0800
Subject: [Patches] [ python-Patches-663369 ] (email) Escape backslashes in specialsre and escapesre
Message-ID: <E18Vfu9-0006BQ-00@sc8-sf-web4.sourceforge.net>

Patches item #663369, was opened at 2003-01-06 22:37
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663369&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Woodcraft (mhf)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: (email) Escape backslashes in specialsre and escapesre

Initial Comment:
(email/Utils.py) Escape backslashes in character
classes in specialsre and escapesre.

Patch against sourceforge CVS as of 2003-01-06
python/dist/src/Lib/email/Utils.py  rev 1.21
python/dist/src/Lib/email/test/test_email.py  rev 1.29


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

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


From noreply@sourceforge.net  Mon Jan  6 20:13:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 12:13:20 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18Vdce-0007vq-00@sc8-sf-web4.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 16:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

>Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 20:13

Message:
Logged In: YES 
user_id=679947

I changed 'except SyntaxError:' to 'except Exception:' since
compileall.py has the 'except:' clause in the following:
                try:
                    ok = py_compile.compile(fullname, None,
dfile)
                except KeyboardInterrupt:
                    raise KeyboardInterrupt
                except:
                    # XXX py_compile catches SyntaxErrors
                    if type(sys.exc_type) == type(''):
                        exc_type_name = sys.exc_type
                     ...

If this block is not necessary, then I can simplify things
somewhat. The test for string exceptions was taken from here
as well. 

Should I assume that only class-based and SyntaxError
exceptions can occur from __builtin__.compile? 
(I looked at compile.c, and from my
non-c-programmer-perspective, it looks like other exceptions
can be raised. _If I read the code correctly_, it looks like
ValueError, MemoryError, OverflowError, and SystemError can
also occur.)

Attached is the latest diff with most of your suggestions
implemented. I'll work on the documentation.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 15:30

Message:
Logged In: YES 
user_id=21627

I'm still unsure why you replace the except SyntaxError: with 
except Exception:. What other exceptions could occur in this 
place? Also, calling exc_info isn't necessary - you could 
obtain the exception value in the catch clause. Unless you 
are expecting string exceptions (which ones), code to 
support string exceptions should not be needed, and the type 
can be obtained by looking at __class__.

Don't compare types by comparing their names: to find out 
whether t is SyntaxError, write 't is SyntaxError', 
not 't.__name__ == "SyntaxError"'.

Exception instances should always have a .args attribute. 
This is best generated by calling the base class __init__ in 
an exception's __init__.

Please provide the documentation changes (docstrings, 
Doc/lib, and a NEWS entry) as well.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 14:48

Message:
Logged In: YES 
user_id=679947

I have implemented a 'doraise' flag in py_compile.compile.
I think the patch should now be backwards-compatible.
However, I think that files that use py_compile in the
standard library (compileall.py and zipfile.py) should
perhaps use the new exception mechanism for clarity and as a
demonstration of how to use the exception.
What do you think?
I'm not sure if I've eliminated the 'few minor issues'. I
did  implement 'except Exception:' instead of a raw
'except:'. Is this what you meant.
Thanks for your comments.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 13:27

Message:
Logged In: YES 
user_id=21627

The patch looks fine so far, except for a few minor issues
(i.e. never to use bare except: clauses). You don't have to
implement a migration strategy: just elaborating it here
would be fine. To preserve compatibility, I could envision a
flag ('doraise' or some such), or a different entry point.
If you manage to provide full backwards compatibility, you
don't need to change any of the existing callers.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 13:15

Message:
Logged In: YES 
user_id=679947

The following patch adds a 'PyCompileError' exception to
py_compile and adds the appropriate 'except' and 'raise'
clauses to py_compile.py, compileall.py, and zipfile.py (I
think that these are the only affected files in the standard
library).
The exception class messages were chosen to try to simulate
the current behavior in these files as closely as possible.

If this patch looks okay (or at least is in the right
direction), I'll begin to look at the documentation and
migration issues.


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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-04 15:20

Message:
Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 23:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 20:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Mon Jan  6 22:04:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 14:04:23 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18VfM7-0004kV-00@sc8-sf-web4.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 23:04

Message:
Logged In: YES 
user_id=21627

You are probably right that other errors can occur in
compile also. However, KeyboardInterrupt must pass through
unmodified, since the user must be able to interrupt
compilation.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 21:13

Message:
Logged In: YES 
user_id=679947

I changed 'except SyntaxError:' to 'except Exception:' since
compileall.py has the 'except:' clause in the following:
                try:
                    ok = py_compile.compile(fullname, None,
dfile)
                except KeyboardInterrupt:
                    raise KeyboardInterrupt
                except:
                    # XXX py_compile catches SyntaxErrors
                    if type(sys.exc_type) == type(''):
                        exc_type_name = sys.exc_type
                     ...

If this block is not necessary, then I can simplify things
somewhat. The test for string exceptions was taken from here
as well. 

Should I assume that only class-based and SyntaxError
exceptions can occur from __builtin__.compile? 
(I looked at compile.c, and from my
non-c-programmer-perspective, it looks like other exceptions
can be raised. _If I read the code correctly_, it looks like
ValueError, MemoryError, OverflowError, and SystemError can
also occur.)

Attached is the latest diff with most of your suggestions
implemented. I'll work on the documentation.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 16:30

Message:
Logged In: YES 
user_id=21627

I'm still unsure why you replace the except SyntaxError: with 
except Exception:. What other exceptions could occur in this 
place? Also, calling exc_info isn't necessary - you could 
obtain the exception value in the catch clause. Unless you 
are expecting string exceptions (which ones), code to 
support string exceptions should not be needed, and the type 
can be obtained by looking at __class__.

Don't compare types by comparing their names: to find out 
whether t is SyntaxError, write 't is SyntaxError', 
not 't.__name__ == "SyntaxError"'.

Exception instances should always have a .args attribute. 
This is best generated by calling the base class __init__ in 
an exception's __init__.

Please provide the documentation changes (docstrings, 
Doc/lib, and a NEWS entry) as well.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 15:48

Message:
Logged In: YES 
user_id=679947

I have implemented a 'doraise' flag in py_compile.compile.
I think the patch should now be backwards-compatible.
However, I think that files that use py_compile in the
standard library (compileall.py and zipfile.py) should
perhaps use the new exception mechanism for clarity and as a
demonstration of how to use the exception.
What do you think?
I'm not sure if I've eliminated the 'few minor issues'. I
did  implement 'except Exception:' instead of a raw
'except:'. Is this what you meant.
Thanks for your comments.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 14:27

Message:
Logged In: YES 
user_id=21627

The patch looks fine so far, except for a few minor issues
(i.e. never to use bare except: clauses). You don't have to
implement a migration strategy: just elaborating it here
would be fine. To preserve compatibility, I could envision a
flag ('doraise' or some such), or a different entry point.
If you manage to provide full backwards compatibility, you
don't need to change any of the existing callers.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 14:15

Message:
Logged In: YES 
user_id=679947

The following patch adds a 'PyCompileError' exception to
py_compile and adds the appropriate 'except' and 'raise'
clauses to py_compile.py, compileall.py, and zipfile.py (I
think that these are the only affected files in the standard
library).
The exception class messages were chosen to try to simulate
the current behavior in these files as closely as possible.

If this patch looks okay (or at least is in the right
direction), I'll begin to look at the documentation and
migration issues.


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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-04 16:20

Message:
Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-04 00:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 21:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Tue Jan  7 21:39:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 13:39:05 -0800
Subject: [Patches] [ python-Patches-664011 ] tarfile documentation misplaced?
Message-ID: <E18W1RB-0001wL-00@sc8-sf-web1.sourceforge.net>

Patches item #664011, was opened at 2003-01-07 22:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664011&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Gustäbel (gustaebel)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile documentation misplaced?

Initial Comment:
At the moment the docs for tarfile are placed in the
section "Miscellaneous Services".
IMHO, it would be far more intuitive if they were
placed in "Optional Operating System Services", right
below the docs for zlib, gzip, bz2 and zipfile.

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

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


From noreply@sourceforge.net  Tue Jan  7 21:40:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 13:40:46 -0800
Subject: [Patches] [ python-Patches-664011 ] tarfile documentation misplaced?
Message-ID: <E18W1So-0000rJ-00@sc8-sf-web3.sourceforge.net>

Patches item #664011, was opened at 2003-01-07 22:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664011&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Lars Gustäbel (gustaebel)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile documentation misplaced?

Initial Comment:
At the moment the docs for tarfile are placed in the
section "Miscellaneous Services".
IMHO, it would be far more intuitive if they were
placed in "Optional Operating System Services", right
below the docs for zlib, gzip, bz2 and zipfile.

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

Comment By: Lars Gustäbel (gustaebel)
Date: 2003-01-07 22:40

Message:
Logged In: YES 
user_id=642936

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Mon Jan  6 22:52:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 14:52:15 -0800
Subject: [Patches] [ python-Patches-662433 ] Fill arraymodule's tp_iter and sq_contains slots
Message-ID: <E18Vg6R-0006c3-00@sc8-sf-web4.sourceforge.net>

Patches item #662433, was opened at 2003-01-04 20:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662433&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Christian Tismer (tismer)
Summary: Fill arraymodule's tp_iter and sq_contains slots

Initial Comment:
Small speedup no change in API.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-06 10:03

Message:
Logged In: YES 
user_id=6380

I have no time to review this code, but I'm +1 on doing this.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-05 15:59

Message:
Logged In: YES 
user_id=80475

New patch has test code and fills both the tp_iter and 
sq_contains slots.  

Matches what we've already done for listobjec, 
tupleobject, and rangeobject to improve their performance.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-01-04 21:43

Message:
Logged In: YES 
user_id=357491

Code looks sound to me.  The  only thing I think it is
missing is tests for the testing suite.

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

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


From noreply@sourceforge.net  Mon Jan  6 22:55:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 14:55:10 -0800
Subject: [Patches] [ python-Patches-661368 ] Add sysexits.h EX_* symbols to posix
Message-ID: <E18Vg9G-0005GL-00@sc8-sf-web1.sourceforge.net>

Patches item #661368, was opened at 2003-01-02 18:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661368&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Add sysexits.h EX_* symbols to posix

Initial Comment:
The following patch adds the EX_* symbols to the posix
module (exposed through os of course).  These are
defined in sysexits.h.  Done this way since the list
can be (slightly) different depending on the OS.  This
patch includes configure updates to detect sysexits.h.

I'll update docs if it's approved for Py2.3.

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-06 17:55

Message:
Logged In: YES 
user_id=12800

Except they aren't alphabetical now. ;)

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 03:10

Message:
Logged In: YES 
user_id=21627

I'm not concerned about the order of symbols in posixmodule,
but about the order of header names in configure.in - those
should be alphabetical.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-02 21:58

Message:
Logged In: YES 
user_id=12800

The order is roughly the order found in Linux's sysexits.h,
which is in numerical order (there is one extra symbol found
in Solaris's sysexit.h that isn't in Linux's).

I'll work out doc updates before I commit.  Thanks for
looking at it.  The configure goo was because I didn't trim
my "cvs diff -u" output. ;)

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-02 19:03

Message:
Logged In: YES 
user_id=21627

Never heard about sysexit.h... The patch looks fine, except
that the list of headers to test should be roughly in
alphabetical order (so that it is easier to spot
duplicates). Please apply it.

In general, there is no need to attach the generated
configure to SF bug reports, it will outdate quickly.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-02 18:46

Message:
Logged In: YES 
user_id=12800

I know all about this PITA, thought I had, guess I didn't. ;(

Trying again...

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-02 18:15

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Tue Jan  7 21:57:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 13:57:13 -0800
Subject: [Patches] [ python-Patches-664020 ] telnetlib option subnegotiation fix
Message-ID: <E18W1ij-0000bN-00@sc8-sf-web4.sourceforge.net>

Patches item #664020, was opened at 2003-01-07 21:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664020&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Reeves (sreeves)
Assigned to: Nobody/Anonymous (nobody)
Summary: telnetlib option subnegotiation fix

Initial Comment:
The telnetlib patch #630829 (committed as v1.20) for
option subnegotiation doesn't work as-is.  There are
several problems.

1) The option negotiation callback should be a method
of the Telnet class, not a separate function.  The
callback is supposed to call the read_sb_data method
when it receives SB or SE, but of which object?

I think the callback should have been a method all
along.  It should be able to change the object's state
based on the negotiation.  Generally when implementing
a new protocol extension, you'll subclass Telnet, add
the new behavior, and then have the callback set a flag
in the object to activate the new behavior after it has
been negotiated.

The default DONT/WONT behavior can be moved out of the
depths of process_rawq() into the callback method. 
Subclasses can then just forward to the parent class
when they get an option they don't care about, instead
of having to reimplement the default behavior.

If the callback is a method, the socket argument is
still available as self.sock.  The
set_option_negotiation_callback method and the checks
for "if self.option_callback:" would not be needed.

Changing the callback to a method will break
compatibility with Python 2.2, however.

2) On receipt of SB and SE, the callback is always
called with NOOPT.  The option is never passed.  (It
actually gets stored as the first part of the parameter
data and returned by read_sb_data().)

3) The callback is called on the receipt of both SB
_and_ SE.  The SB call is completely superfluous.  The
option and parameter data have not been read yet, so
there is nothing for the callback to do.

The attached patch fixes these and adds support for the
NOP command.  It also includes documentation changes
and an example of implementing some options.

Some other thoughts:

The name "option_callback" is a little misleading.  The
callback is executed in response to all telnet protocol
commands, not just the ones dealing with options.

Why define and pass NOOPT for the case when there is no
option rather than use None?

The only place the SB parameter data will (can safely?)
be used is in the callback.  Why not pass it as another
optional parameter and skip the need for read_sb_data()?

A potential name conflict: the EOR telnet option
defines a new command code also called EOR (with a much
different numeric value).  The C header file
<arpa/telnet.h> prefixes all the options with TELOPT_,
so there is no conflict there, but telnetlib drops the
prefix.


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

>Comment By: Steve Reeves (sreeves)
Date: 2003-01-07 21:57

Message:
Logged In: YES 
user_id=2647

Sorry, the patch wasn't uploaded for some reason.  Trying again.


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

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


From noreply@sourceforge.net  Tue Jan  7 00:47:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 16:47:32 -0800
Subject: [Patches] [ python-Patches-662433 ] Fill arraymodule's tp_iter and sq_contains slots
Message-ID: <E18Vhu0-000198-00@sc8-sf-web2.sourceforge.net>

Patches item #662433, was opened at 2003-01-05 02:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662433&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Christian Tismer (tismer)
Summary: Fill arraymodule's tp_iter and sq_contains slots

Initial Comment:
Small speedup no change in API.

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

>Comment By: Christian Tismer (tismer)
Date: 2003-01-07 01:47

Message:
Logged In: YES 
user_id=105700

On Raymond's request, I reviewed this patch thorougly.

The patch correctly implements the iterator protocol for
array objects.
I did a line-by-line comparison to the according code in the
listobject.c file, after actualizing my CVS snapshot.

The implementation looks *very* clean and accurate to me.

Just two tiny comments:
- There is a space/tab glitch in array_iter at
        it = PyObject_GC_New(arrayiterobject,
&PyArrayIter_Type);

- comparison of similar iterator implementations across
modules would be further simplified, if the methods were
always written in the same order.

- if the C language had templates, this patch would be
*very* short. We shoukd consider to write a tiny template
system in Python, which creates code like this.

Conclusion:
Objectively,  this patch has no obvious errors.
Subjectively, this patch obviously has no errors.
I am +1 on applying it now, and I will help if I was wrong
about its correctness.

sincerely -- chris


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-06 16:03

Message:
Logged In: YES 
user_id=6380

I have no time to review this code, but I'm +1 on doing this.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-05 21:59

Message:
Logged In: YES 
user_id=80475

New patch has test code and fills both the tp_iter and 
sq_contains slots.  

Matches what we've already done for listobjec, 
tupleobject, and rangeobject to improve their performance.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-01-05 03:43

Message:
Logged In: YES 
user_id=357491

Code looks sound to me.  The  only thing I think it is
missing is tests for the testing suite.

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

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


From noreply@sourceforge.net  Tue Jan  7 02:05:22 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 18:05:22 -0800
Subject: [Patches] [ python-Patches-662433 ] Fill arraymodule's tp_iter and sq_contains slots
Message-ID: <E18Vj7K-0003iK-00@sc8-sf-web1.sourceforge.net>

Patches item #662433, was opened at 2003-01-04 20:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662433&group_id=5470

Category: Modules
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Christian Tismer (tismer)
Summary: Fill arraymodule's tp_iter and sq_contains slots

Initial Comment:
Small speedup no change in API.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-06 21:05

Message:
Logged In: YES 
user_id=80475

Committed as:
Modules/arraymodule.c 2.82
Lib/test/test_array.py 1.19

Closing patch.
Chris to mark the resolution.

Thank you Brett for the initial review, GvR for the go-
ahead, and Chris for the detail review.

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

Comment By: Christian Tismer (tismer)
Date: 2003-01-06 19:47

Message:
Logged In: YES 
user_id=105700

On Raymond's request, I reviewed this patch thorougly.

The patch correctly implements the iterator protocol for
array objects.
I did a line-by-line comparison to the according code in the
listobject.c file, after actualizing my CVS snapshot.

The implementation looks *very* clean and accurate to me.

Just two tiny comments:
- There is a space/tab glitch in array_iter at
        it = PyObject_GC_New(arrayiterobject,
&PyArrayIter_Type);

- comparison of similar iterator implementations across
modules would be further simplified, if the methods were
always written in the same order.

- if the C language had templates, this patch would be
*very* short. We shoukd consider to write a tiny template
system in Python, which creates code like this.

Conclusion:
Objectively,  this patch has no obvious errors.
Subjectively, this patch obviously has no errors.
I am +1 on applying it now, and I will help if I was wrong
about its correctness.

sincerely -- chris


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-06 10:03

Message:
Logged In: YES 
user_id=6380

I have no time to review this code, but I'm +1 on doing this.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-05 15:59

Message:
Logged In: YES 
user_id=80475

New patch has test code and fills both the tp_iter and 
sq_contains slots.  

Matches what we've already done for listobjec, 
tupleobject, and rangeobject to improve their performance.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-01-04 21:43

Message:
Logged In: YES 
user_id=357491

Code looks sound to me.  The  only thing I think it is
missing is tests for the testing suite.

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

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


From noreply@sourceforge.net  Tue Jan  7 03:42:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 06 Jan 2003 19:42:18 -0800
Subject: [Patches] [ python-Patches-663482 ] 658254: accept None for time.ctime() and friends
Message-ID: <E18Vkd8-0006xw-00@sc8-sf-web4.sourceforge.net>

Patches item #663482, was opened at 2003-01-06 22:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663482&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Nobody/Anonymous (nobody)
Summary: 658254: accept None for time.ctime() and friends

Initial Comment:
ctime(), gmtime(), and localtime() now support None and
treat it as tho you passed no arguments at all.

i am new to patching for py and am not sure if there
are unit tests i should update.  please advise...

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

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


From noreply@sourceforge.net  Tue Jan  7 22:33:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 14:33:45 -0800
Subject: [Patches] [ python-Patches-663482 ] 658254: accept None for time.ctime() and friends
Message-ID: <E18W2I5-00040r-00@sc8-sf-web1.sourceforge.net>

Patches item #663482, was opened at 2003-01-06 22:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663482&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Nobody/Anonymous (nobody)
Summary: 658254: accept None for time.ctime() and friends

Initial Comment:
ctime(), gmtime(), and localtime() now support None and
treat it as tho you passed no arguments at all.

i am new to patching for py and am not sure if there
are unit tests i should update.  please advise...

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-07 17:33

Message:
Logged In: YES 
user_id=33168

There don't appear to be any direct tests, but it would
still be nice to call the functions and verify they work ok.
 You could compare that abs(ctime() - ctime(None)) < .5, for
example.  Look in Lib/test/test_time.py.

Also, the docs need to be updated, see Doc/lib/libtime.tex.
 That should be updated, ie change \optional(secs) with
\optional{secs\code{ = None}}.  Also, an entry in Misc/NEWS
should be added since this is an API change.

There is no attached file.

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

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


From noreply@sourceforge.net  Tue Jan  7 22:38:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 14:38:02 -0800
Subject: [Patches] [ python-Patches-664011 ] tarfile documentation misplaced?
Message-ID: <E18W2ME-0003TY-00@sc8-sf-web3.sourceforge.net>

Patches item #664011, was opened at 2003-01-07 16:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664011&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Lars Gustäbel (gustaebel)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: tarfile documentation misplaced?

Initial Comment:
At the moment the docs for tarfile are placed in the
section "Miscellaneous Services".
IMHO, it would be far more intuitive if they were
placed in "Optional Operating System Services", right
below the docs for zlib, gzip, bz2 and zipfile.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-07 17:38

Message:
Logged In: YES 
user_id=33168

Checked in as 1.213

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

Comment By: Lars Gustäbel (gustaebel)
Date: 2003-01-07 16:40

Message:
Logged In: YES 
user_id=642936

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Tue Jan  7 13:30:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 05:30:31 -0800
Subject: [Patches] [ python-Patches-662433 ] Fill arraymodule's tp_iter and sq_contains slots
Message-ID: <E18VtoN-0002hX-00@sc8-sf-web1.sourceforge.net>

Patches item #662433, was opened at 2003-01-05 02:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662433&group_id=5470

Category: Modules
Group: Python 2.3
Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Christian Tismer (tismer)
Summary: Fill arraymodule's tp_iter and sq_contains slots

Initial Comment:
Small speedup no change in API.

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

>Comment By: Christian Tismer (tismer)
Date: 2003-01-07 14:30

Message:
Logged In: YES 
user_id=105700

It was a delight to do this review.
Thanks to Raymond.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-07 03:05

Message:
Logged In: YES 
user_id=80475

Committed as:
Modules/arraymodule.c 2.82
Lib/test/test_array.py 1.19

Closing patch.
Chris to mark the resolution.

Thank you Brett for the initial review, GvR for the go-
ahead, and Chris for the detail review.

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

Comment By: Christian Tismer (tismer)
Date: 2003-01-07 01:47

Message:
Logged In: YES 
user_id=105700

On Raymond's request, I reviewed this patch thorougly.

The patch correctly implements the iterator protocol for
array objects.
I did a line-by-line comparison to the according code in the
listobject.c file, after actualizing my CVS snapshot.

The implementation looks *very* clean and accurate to me.

Just two tiny comments:
- There is a space/tab glitch in array_iter at
        it = PyObject_GC_New(arrayiterobject,
&PyArrayIter_Type);

- comparison of similar iterator implementations across
modules would be further simplified, if the methods were
always written in the same order.

- if the C language had templates, this patch would be
*very* short. We shoukd consider to write a tiny template
system in Python, which creates code like this.

Conclusion:
Objectively,  this patch has no obvious errors.
Subjectively, this patch obviously has no errors.
I am +1 on applying it now, and I will help if I was wrong
about its correctness.

sincerely -- chris


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-06 16:03

Message:
Logged In: YES 
user_id=6380

I have no time to review this code, but I'm +1 on doing this.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-05 21:59

Message:
Logged In: YES 
user_id=80475

New patch has test code and fills both the tp_iter and 
sq_contains slots.  

Matches what we've already done for listobjec, 
tupleobject, and rangeobject to improve their performance.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-01-05 03:43

Message:
Logged In: YES 
user_id=357491

Code looks sound to me.  The  only thing I think it is
missing is tests for the testing suite.

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

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


From noreply@sourceforge.net  Tue Jan  7 14:16:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 06:16:35 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18VuWx-00049C-00@sc8-sf-web4.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 16:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

>Comment By: Gyro Funch (siva1311)
Date: 2003-01-07 14:16

Message:
Logged In: YES 
user_id=679947

Attached is a patch that includes changes to the source and
documentation.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 22:04

Message:
Logged In: YES 
user_id=21627

You are probably right that other errors can occur in
compile also. However, KeyboardInterrupt must pass through
unmodified, since the user must be able to interrupt
compilation.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 20:13

Message:
Logged In: YES 
user_id=679947

I changed 'except SyntaxError:' to 'except Exception:' since
compileall.py has the 'except:' clause in the following:
                try:
                    ok = py_compile.compile(fullname, None,
dfile)
                except KeyboardInterrupt:
                    raise KeyboardInterrupt
                except:
                    # XXX py_compile catches SyntaxErrors
                    if type(sys.exc_type) == type(''):
                        exc_type_name = sys.exc_type
                     ...

If this block is not necessary, then I can simplify things
somewhat. The test for string exceptions was taken from here
as well. 

Should I assume that only class-based and SyntaxError
exceptions can occur from __builtin__.compile? 
(I looked at compile.c, and from my
non-c-programmer-perspective, it looks like other exceptions
can be raised. _If I read the code correctly_, it looks like
ValueError, MemoryError, OverflowError, and SystemError can
also occur.)

Attached is the latest diff with most of your suggestions
implemented. I'll work on the documentation.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 15:30

Message:
Logged In: YES 
user_id=21627

I'm still unsure why you replace the except SyntaxError: with 
except Exception:. What other exceptions could occur in this 
place? Also, calling exc_info isn't necessary - you could 
obtain the exception value in the catch clause. Unless you 
are expecting string exceptions (which ones), code to 
support string exceptions should not be needed, and the type 
can be obtained by looking at __class__.

Don't compare types by comparing their names: to find out 
whether t is SyntaxError, write 't is SyntaxError', 
not 't.__name__ == "SyntaxError"'.

Exception instances should always have a .args attribute. 
This is best generated by calling the base class __init__ in 
an exception's __init__.

Please provide the documentation changes (docstrings, 
Doc/lib, and a NEWS entry) as well.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 14:48

Message:
Logged In: YES 
user_id=679947

I have implemented a 'doraise' flag in py_compile.compile.
I think the patch should now be backwards-compatible.
However, I think that files that use py_compile in the
standard library (compileall.py and zipfile.py) should
perhaps use the new exception mechanism for clarity and as a
demonstration of how to use the exception.
What do you think?
I'm not sure if I've eliminated the 'few minor issues'. I
did  implement 'except Exception:' instead of a raw
'except:'. Is this what you meant.
Thanks for your comments.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 13:27

Message:
Logged In: YES 
user_id=21627

The patch looks fine so far, except for a few minor issues
(i.e. never to use bare except: clauses). You don't have to
implement a migration strategy: just elaborating it here
would be fine. To preserve compatibility, I could envision a
flag ('doraise' or some such), or a different entry point.
If you manage to provide full backwards compatibility, you
don't need to change any of the existing callers.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 13:15

Message:
Logged In: YES 
user_id=679947

The following patch adds a 'PyCompileError' exception to
py_compile and adds the appropriate 'except' and 'raise'
clauses to py_compile.py, compileall.py, and zipfile.py (I
think that these are the only affected files in the standard
library).
The exception class messages were chosen to try to simulate
the current behavior in these files as closely as possible.

If this patch looks okay (or at least is in the right
direction), I'll begin to look at the documentation and
migration issues.


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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-04 15:20

Message:
Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 23:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 20:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Tue Jan  7 14:35:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 06:35:38 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18VupO-0005n6-00@sc8-sf-web1.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 16:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

>Comment By: Gyro Funch (siva1311)
Date: 2003-01-07 14:35

Message:
Logged In: YES 
user_id=679947

Attached is a patch that includes changes to the source and
documentation.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-07 14:16

Message:
Logged In: YES 
user_id=679947

Attached is a patch that includes changes to the source and
documentation.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 22:04

Message:
Logged In: YES 
user_id=21627

You are probably right that other errors can occur in
compile also. However, KeyboardInterrupt must pass through
unmodified, since the user must be able to interrupt
compilation.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 20:13

Message:
Logged In: YES 
user_id=679947

I changed 'except SyntaxError:' to 'except Exception:' since
compileall.py has the 'except:' clause in the following:
                try:
                    ok = py_compile.compile(fullname, None,
dfile)
                except KeyboardInterrupt:
                    raise KeyboardInterrupt
                except:
                    # XXX py_compile catches SyntaxErrors
                    if type(sys.exc_type) == type(''):
                        exc_type_name = sys.exc_type
                     ...

If this block is not necessary, then I can simplify things
somewhat. The test for string exceptions was taken from here
as well. 

Should I assume that only class-based and SyntaxError
exceptions can occur from __builtin__.compile? 
(I looked at compile.c, and from my
non-c-programmer-perspective, it looks like other exceptions
can be raised. _If I read the code correctly_, it looks like
ValueError, MemoryError, OverflowError, and SystemError can
also occur.)

Attached is the latest diff with most of your suggestions
implemented. I'll work on the documentation.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 15:30

Message:
Logged In: YES 
user_id=21627

I'm still unsure why you replace the except SyntaxError: with 
except Exception:. What other exceptions could occur in this 
place? Also, calling exc_info isn't necessary - you could 
obtain the exception value in the catch clause. Unless you 
are expecting string exceptions (which ones), code to 
support string exceptions should not be needed, and the type 
can be obtained by looking at __class__.

Don't compare types by comparing their names: to find out 
whether t is SyntaxError, write 't is SyntaxError', 
not 't.__name__ == "SyntaxError"'.

Exception instances should always have a .args attribute. 
This is best generated by calling the base class __init__ in 
an exception's __init__.

Please provide the documentation changes (docstrings, 
Doc/lib, and a NEWS entry) as well.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 14:48

Message:
Logged In: YES 
user_id=679947

I have implemented a 'doraise' flag in py_compile.compile.
I think the patch should now be backwards-compatible.
However, I think that files that use py_compile in the
standard library (compileall.py and zipfile.py) should
perhaps use the new exception mechanism for clarity and as a
demonstration of how to use the exception.
What do you think?
I'm not sure if I've eliminated the 'few minor issues'. I
did  implement 'except Exception:' instead of a raw
'except:'. Is this what you meant.
Thanks for your comments.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 13:27

Message:
Logged In: YES 
user_id=21627

The patch looks fine so far, except for a few minor issues
(i.e. never to use bare except: clauses). You don't have to
implement a migration strategy: just elaborating it here
would be fine. To preserve compatibility, I could envision a
flag ('doraise' or some such), or a different entry point.
If you manage to provide full backwards compatibility, you
don't need to change any of the existing callers.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 13:15

Message:
Logged In: YES 
user_id=679947

The following patch adds a 'PyCompileError' exception to
py_compile and adds the appropriate 'except' and 'raise'
clauses to py_compile.py, compileall.py, and zipfile.py (I
think that these are the only affected files in the standard
library).
The exception class messages were chosen to try to simulate
the current behavior in these files as closely as possible.

If this patch looks okay (or at least is in the right
direction), I'll begin to look at the documentation and
migration issues.


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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-04 15:20

Message:
Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 23:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 21:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 20:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Tue Jan  7 16:37:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 08:37:32 -0800
Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest
Message-ID: <E18VwjM-0004J5-00@sc8-sf-web1.sourceforge.net>

Patches item #662807, was opened at 2003-01-05 21:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Port tests to unittest

Initial Comment:
This patch ports the three tests test_pow.py, 
test_charmapcodec.py and test_userdict.py to unittest.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-07 17:37

Message:
Logged In: YES 
user_id=89016

test_b1.py has been ported too.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-05 21:56

Message:
Logged In: YES 
user_id=89016

The patch is hard to read, so I'll upload all three test scripts.

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

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


From noreply@sourceforge.net  Tue Jan  7 20:21:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 12:21:38 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18W0EE-0004j4-00@sc8-sf-web4.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
>Assigned to: Martin v. Löwis (loewis)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-07 15:35

Message:
Logged In: YES 
user_id=679947

Attached is a patch that includes changes to the source and
documentation.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-07 15:16

Message:
Logged In: YES 
user_id=679947

Attached is a patch that includes changes to the source and
documentation.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 23:04

Message:
Logged In: YES 
user_id=21627

You are probably right that other errors can occur in
compile also. However, KeyboardInterrupt must pass through
unmodified, since the user must be able to interrupt
compilation.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 21:13

Message:
Logged In: YES 
user_id=679947

I changed 'except SyntaxError:' to 'except Exception:' since
compileall.py has the 'except:' clause in the following:
                try:
                    ok = py_compile.compile(fullname, None,
dfile)
                except KeyboardInterrupt:
                    raise KeyboardInterrupt
                except:
                    # XXX py_compile catches SyntaxErrors
                    if type(sys.exc_type) == type(''):
                        exc_type_name = sys.exc_type
                     ...

If this block is not necessary, then I can simplify things
somewhat. The test for string exceptions was taken from here
as well. 

Should I assume that only class-based and SyntaxError
exceptions can occur from __builtin__.compile? 
(I looked at compile.c, and from my
non-c-programmer-perspective, it looks like other exceptions
can be raised. _If I read the code correctly_, it looks like
ValueError, MemoryError, OverflowError, and SystemError can
also occur.)

Attached is the latest diff with most of your suggestions
implemented. I'll work on the documentation.


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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 16:30

Message:
Logged In: YES 
user_id=21627

I'm still unsure why you replace the except SyntaxError: with 
except Exception:. What other exceptions could occur in this 
place? Also, calling exc_info isn't necessary - you could 
obtain the exception value in the catch clause. Unless you 
are expecting string exceptions (which ones), code to 
support string exceptions should not be needed, and the type 
can be obtained by looking at __class__.

Don't compare types by comparing their names: to find out 
whether t is SyntaxError, write 't is SyntaxError', 
not 't.__name__ == "SyntaxError"'.

Exception instances should always have a .args attribute. 
This is best generated by calling the base class __init__ in 
an exception's __init__.

Please provide the documentation changes (docstrings, 
Doc/lib, and a NEWS entry) as well.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 15:48

Message:
Logged In: YES 
user_id=679947

I have implemented a 'doraise' flag in py_compile.compile.
I think the patch should now be backwards-compatible.
However, I think that files that use py_compile in the
standard library (compileall.py and zipfile.py) should
perhaps use the new exception mechanism for clarity and as a
demonstration of how to use the exception.
What do you think?
I'm not sure if I've eliminated the 'few minor issues'. I
did  implement 'except Exception:' instead of a raw
'except:'. Is this what you meant.
Thanks for your comments.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 14:27

Message:
Logged In: YES 
user_id=21627

The patch looks fine so far, except for a few minor issues
(i.e. never to use bare except: clauses). You don't have to
implement a migration strategy: just elaborating it here
would be fine. To preserve compatibility, I could envision a
flag ('doraise' or some such), or a different entry point.
If you manage to provide full backwards compatibility, you
don't need to change any of the existing callers.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 14:15

Message:
Logged In: YES 
user_id=679947

The following patch adds a 'PyCompileError' exception to
py_compile and adds the appropriate 'except' and 'raise'
clauses to py_compile.py, compileall.py, and zipfile.py (I
think that these are the only affected files in the standard
library).
The exception class messages were chosen to try to simulate
the current behavior in these files as closely as possible.

If this patch looks okay (or at least is in the right
direction), I'll begin to look at the documentation and
migration issues.


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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-04 16:20

Message:
Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-04 00:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

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

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 21:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

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

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


From noreply@sourceforge.net  Tue Jan  7 20:42:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 12:42:46 -0800
Subject: [Patches] [ python-Patches-663983 ] PyList_NewNoZero
Message-ID: <E18W0Yg-0004Cc-00@sc8-sf-web2.sourceforge.net>

Patches item #663983, was opened at 2003-01-07 15:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663983&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyList_NewNoZero

Initial Comment:
PyList_New(n) spends time initializing every space to 
zero.  In many (but not all cases), the caller 
immediately refills in every space and has no error 
exits prior to filling the space.  In those cases, time 
would be saved by using a version of PyList_New(n) 
that did not do the initialization.

The same holds true for tuples.

Creating new lists and tuples is one of the most 
common operations in python and may warrant this 
micro-optimization.

The attached patch is a proof-of-concept.

The only downside is that it shares the same risks as 
it SET_ITEM macro cousins -- the user of the function 
has the burden of making sure that certain conditions 
hold (in the case, promising to fill out every entry with 
a valid python object or NULL).

Guido, what do you think?  If it gets a plus one, I can 
make a more thorough patch and get a detailed 
review.

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

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


From noreply@sourceforge.net  Tue Jan  7 20:51:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 12:51:56 -0800
Subject: [Patches] [ python-Patches-663983 ] PyList_NewNoZero
Message-ID: <E18W0hY-000630-00@sc8-sf-web4.sourceforge.net>

Patches item #663983, was opened at 2003-01-07 15:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663983&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyList_NewNoZero

Initial Comment:
PyList_New(n) spends time initializing every space to 
zero.  In many (but not all cases), the caller 
immediately refills in every space and has no error 
exits prior to filling the space.  In those cases, time 
would be saved by using a version of PyList_New(n) 
that did not do the initialization.

The same holds true for tuples.

Creating new lists and tuples is one of the most 
common operations in python and may warrant this 
micro-optimization.

The attached patch is a proof-of-concept.

The only downside is that it shares the same risks as 
it SET_ITEM macro cousins -- the user of the function 
has the burden of making sure that certain conditions 
hold (in the case, promising to fill out every entry with 
a valid python object or NULL).

Guido, what do you think?  If it gets a plus one, I can 
make a more thorough patch and get a detailed 
review.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-07 15:51

Message:
Logged In: YES 
user_id=6380

I'm not comfortable with this, I find it hard to believe
that a memset() can make much difference given everything
else that goes on (like INCREF'ing every single thing that
gets stored in a list even by PyList_SET_ITEM), I see no
performance data backing up the change, and I would like to
keep the annual growth of Python within bounds. So, -1.

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

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


From noreply@sourceforge.net  Wed Jan  8 02:14:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 18:14:02 -0800
Subject: [Patches] [ python-Patches-664131 ] distutils config exe_extension on Mac OS X, Linux
Message-ID: <E18W5jG-0001Ju-00@sc8-sf-web4.sourceforge.net>

Patches item #664131, was opened at 2003-01-08 11:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664131&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michiel de Hoon (mdehoon)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils config exe_extension on Mac OS X, Linux

Initial Comment:
I have been using distutils' "python setup.py config"
command in order to do some configuration steps before
the build and install.
On Linux and Mac OS X, when doing trial compilations I
get this error: 

  File
"/usr/local/lib/python2.3/distutils/command/config.py",
line 154, in _link
    prog = prog + self.compiler.exe_extension
TypeError: cannot concatenate 'str' and 'NoneType' objects

The problem is that on Mac OS X and Linux,
self.compiler.exe_extension is None instead of "", and
Python doesn't allow None to be concatenated with a
string. The solution would be either to set
self.compiler.exe_extension to "" instead of None, or
to check if self.compiler.exe_extension is None before
concatenating. The attached patch does the latter:

if self.compiler.exe_extension:
    prog = prog + self.compiler.exe_extension

Changing self.compiler.exe_extension to "" instead of
None may be a cleaner solution, but I don't know how
that would affect other parts of the distutils, which
is why I went with the solution above.


Michiel de Hoon (mdehoon@ims.u-tokyo.ac.jp)
University of Tokyo, Human Genome Center

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

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


From noreply@sourceforge.net  Tue Jan  7 21:51:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 13:51:41 -0800
Subject: [Patches] [ python-Patches-664020 ] telnetlib option subnegotiation fix
Message-ID: <E18W1dN-0002bn-00@sc8-sf-web1.sourceforge.net>

Patches item #664020, was opened at 2003-01-07 21:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664020&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Reeves (sreeves)
Assigned to: Nobody/Anonymous (nobody)
Summary: telnetlib option subnegotiation fix

Initial Comment:
The telnetlib patch #630829 (committed as v1.20) for
option subnegotiation doesn't work as-is.  There are
several problems.

1) The option negotiation callback should be a method
of the Telnet class, not a separate function.  The
callback is supposed to call the read_sb_data method
when it receives SB or SE, but of which object?

I think the callback should have been a method all
along.  It should be able to change the object's state
based on the negotiation.  Generally when implementing
a new protocol extension, you'll subclass Telnet, add
the new behavior, and then have the callback set a flag
in the object to activate the new behavior after it has
been negotiated.

The default DONT/WONT behavior can be moved out of the
depths of process_rawq() into the callback method. 
Subclasses can then just forward to the parent class
when they get an option they don't care about, instead
of having to reimplement the default behavior.

If the callback is a method, the socket argument is
still available as self.sock.  The
set_option_negotiation_callback method and the checks
for "if self.option_callback:" would not be needed.

Changing the callback to a method will break
compatibility with Python 2.2, however.

2) On receipt of SB and SE, the callback is always
called with NOOPT.  The option is never passed.  (It
actually gets stored as the first part of the parameter
data and returned by read_sb_data().)

3) The callback is called on the receipt of both SB
_and_ SE.  The SB call is completely superfluous.  The
option and parameter data have not been read yet, so
there is nothing for the callback to do.

The attached patch fixes these and adds support for the
NOP command.  It also includes documentation changes
and an example of implementing some options.

Some other thoughts:

The name "option_callback" is a little misleading.  The
callback is executed in response to all telnet protocol
commands, not just the ones dealing with options.

Why define and pass NOOPT for the case when there is no
option rather than use None?

The only place the SB parameter data will (can safely?)
be used is in the callback.  Why not pass it as another
optional parameter and skip the need for read_sb_data()?

A potential name conflict: the EOR telnet option
defines a new command code also called EOR (with a much
different numeric value).  The C header file
<arpa/telnet.h> prefixes all the options with TELOPT_,
so there is no conflict there, but telnetlib drops the
prefix.


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

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


From noreply@sourceforge.net  Wed Jan  8 05:15:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 21:15:09 -0800
Subject: [Patches] [ python-Patches-664183 ] 664044: 2.2.6.2 String formatting operations
Message-ID: <E18W8YX-0005XK-00@sc8-sf-web3.sourceforge.net>

Patches item #664183, was opened at 2003-01-08 00:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664183&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Nobody/Anonymous (nobody)
Summary: 664044: 2.2.6.2 String formatting operations

Initial Comment:
Documentation states that format % object returns a
Unicode string if either format or object are unicode.
 However, in the conversion table, the documentation
for the conversion "s" states that a String will be
returned.  It does not state that a unicode String will
be returned if the formatter is u"s" or if the object
being converted is unicode.  

I added a note to clarify the conversion table.  It
simply states that in the event of a unicode formatter
or a unicode string being converted, a unicode string
(not a regular string) will be returned.

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

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


From noreply@sourceforge.net  Wed Jan  8 05:27:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 07 Jan 2003 21:27:35 -0800
Subject: [Patches] [ python-Patches-664192 ] 661913: inconsistent error messages between string an unicod
Message-ID: <E18W8kZ-0006gx-00@sc8-sf-web2.sourceforge.net>

Patches item #664192, was opened at 2003-01-08 00:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664192&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Nobody/Anonymous (nobody)
Summary: 661913: inconsistent error messages between string an unicod

Initial Comment:
'a'.index('b'):   substring not found in index
u'a'.index('b'): substring not found     (bah!)

same thing follows for rindex.

changed unicodeobject.c to return same error message as
what string returns.



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

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


From noreply@sourceforge.net  Wed Jan  8 09:20:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 01:20:25 -0800
Subject: [Patches] [ python-Patches-654910 ] Fix bug in IE/CGI [bug 427345]
Message-ID: <E18WCNt-00067X-00@sc8-sf-web2.sourceforge.net>

Patches item #654910, was opened at 2002-12-17 00:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=654910&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Steve Holden (holdenweb)
>Assigned to: Martin v. Löwis (loewis)
Summary: Fix bug in IE/CGI [bug 427345]

Initial Comment:
This patch fixes Unix (have_fork) and Windows 
(have_popen2 or have_popen3) CGI scripts to cope with 
Internet Explorer's "mozilla emulation", whereby it 
appears to send a couple extra bytes [CRLF?] at the 
end of requests when KeepAlive isn't in use.

While the bug is believed to only affect requests using 
method POST, the code is written to ignore extra bytes 
in any request triggering a CGI call on these platforms. It 
wasn't obvious how to apply similar fixes to the 
third, "other platform" branch.

The whole *HTTPServer family appears to need some 
sort of unified rewrite, but it's difficult to see how that will 
happen.


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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-12-17 07:47

Message:
Logged In: YES 
user_id=250749

The patch file is missing.

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

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


From noreply@sourceforge.net  Wed Jan  8 11:34:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 03:34:07 -0800
Subject: [Patches] [ python-Patches-664320 ] Replace pop/push pairs in ceval.c
Message-ID: <E18WETH-00013v-00@sc8-sf-web3.sourceforge.net>

Patches item #664320, was opened at 2003-01-08 06:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jeremy Hylton (jhylton)
Summary: Replace pop/push pairs in ceval.c

Initial Comment:
Paired PUSH() and POP() macros unnecessarily 
decrement and then re-increment the stack pointer.  
In these cases, indexed access to and from the stack 
is faster.

Saves the add 4 and sub 4 in the assembler code. 
Allows the compiler more freedom to optimize (by 
not overspecifying or creating sequential 
interdependencies). Lets the processor run more of 
the instructions in parallel (adjusting the index 
prevents parallel execution any move or other 
instruction that depends on the index).

I wouldn't begin to know how to time the savings 
here, but examining the  generated assembler shows 
that the code has improved.

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

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


From noreply@sourceforge.net  Wed Jan  8 13:26:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 05:26:44 -0800
Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname
Message-ID: <E18WGEG-0006Ex-00@sc8-sf-web2.sourceforge.net>

Patches item #664376, was opened at 2003-01-08 14:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.path[0] should contain absolute pathname

Initial Comment:
This patch changes sys.path[0] to contain an absolute 
instead of a relative pathname.

See python-dev thread starting here:
http://mail.python.org/pipermail/python-dev/2003-
January/031896.html

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

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


From noreply@sourceforge.net  Wed Jan  8 13:31:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 05:31:56 -0800
Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname
Message-ID: <E18WGJI-00074c-00@sc8-sf-web4.sourceforge.net>

Patches item #664376, was opened at 2003-01-08 14:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.path[0] should contain absolute pathname

Initial Comment:
This patch changes sys.path[0] to contain an absolute 
instead of a relative pathname.

See python-dev thread starting here:
http://mail.python.org/pipermail/python-dev/2003-
January/031896.html

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

>Comment By: Thomas Heller (theller)
Date: 2003-01-08 14:31

Message:
Logged In: YES 
user_id=11105

The attached patch (sysmodule.diff) fixes the problem on 
Windows - that's the only system where I can test it.

It leaves sys.argv alone and only changes sys.path[0] to an 
absolute pathname.


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

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


From noreply@sourceforge.net  Wed Jan  8 14:00:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 06:00:31 -0800
Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname
Message-ID: <E18WGkx-0008Ic-00@sc8-sf-web4.sourceforge.net>

Patches item #664376, was opened at 2003-01-08 08:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Thomas Heller (theller)
Summary: sys.path[0] should contain absolute pathname

Initial Comment:
This patch changes sys.path[0] to contain an absolute 
instead of a relative pathname.

See python-dev thread starting here:
http://mail.python.org/pipermail/python-dev/2003-
January/031896.html

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 09:00

Message:
Logged In: YES 
user_id=6380

Feel free to check this in.

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

Comment By: Thomas Heller (theller)
Date: 2003-01-08 08:31

Message:
Logged In: YES 
user_id=11105

The attached patch (sysmodule.diff) fixes the problem on 
Windows - that's the only system where I can test it.

It leaves sys.argv alone and only changes sys.path[0] to an 
absolute pathname.


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

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


From noreply@sourceforge.net  Wed Jan  8 14:03:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 06:03:54 -0800
Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest
Message-ID: <E18WGoE-0000nA-00@sc8-sf-web3.sourceforge.net>

Patches item #662807, was opened at 2003-01-05 15:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Port tests to unittest

Initial Comment:
This patch ports the three tests test_pow.py, 
test_charmapcodec.py and test_userdict.py to unittest.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 09:03

Message:
Logged In: YES 
user_id=6380

Two random suggestions:

- a blank line before each method, even trivial ones, even
the first one

- use assertEqual, not assertEquals

BTW, I see you've picked up on the convention that unit test
methods should not have doc strings. Good! (But they may
have comments.)

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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-07 11:37

Message:
Logged In: YES 
user_id=89016

test_b1.py has been ported too.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-05 15:56

Message:
Logged In: YES 
user_id=89016

The patch is hard to read, so I'll upload all three test scripts.

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

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


From noreply@sourceforge.net  Wed Jan  8 15:02:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 07:02:43 -0800
Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname
Message-ID: <E18WHj9-0002nt-00@sc8-sf-web2.sourceforge.net>

Patches item #664376, was opened at 2003-01-08 14:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470

Category: None
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: sys.path[0] should contain absolute pathname

Initial Comment:
This patch changes sys.path[0] to contain an absolute 
instead of a relative pathname.

See python-dev thread starting here:
http://mail.python.org/pipermail/python-dev/2003-
January/031896.html

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

>Comment By: Thomas Heller (theller)
Date: 2003-01-08 16:02

Message:
Logged In: YES 
user_id=11105

Checked in as sysmodule.c, rev 2.112.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 15:00

Message:
Logged In: YES 
user_id=6380

Feel free to check this in.

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

Comment By: Thomas Heller (theller)
Date: 2003-01-08 14:31

Message:
Logged In: YES 
user_id=11105

The attached patch (sysmodule.diff) fixes the problem on 
Windows - that's the only system where I can test it.

It leaves sys.argv alone and only changes sys.path[0] to an 
absolute pathname.


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

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


From noreply@sourceforge.net  Wed Jan  8 15:18:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 07:18:11 -0800
Subject: [Patches] [ python-Patches-654910 ] Fix bug in IE/CGI [bug 427345]
Message-ID: <E18WHy7-0003ZU-00@sc8-sf-web2.sourceforge.net>

Patches item #654910, was opened at 2002-12-16 18:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=654910&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
>Resolution: Accepted
Priority: 4
Submitted By: Steve Holden (holdenweb)
Assigned to: Martin v. Löwis (loewis)
Summary: Fix bug in IE/CGI [bug 427345]

Initial Comment:
This patch fixes Unix (have_fork) and Windows 
(have_popen2 or have_popen3) CGI scripts to cope with 
Internet Explorer's "mozilla emulation", whereby it 
appears to send a couple extra bytes [CRLF?] at the 
end of requests when KeepAlive isn't in use.

While the bug is believed to only affect requests using 
method POST, the code is written to ignore extra bytes 
in any request triggering a CGI call on these platforms. It 
wasn't obvious how to apply similar fixes to the 
third, "other platform" branch.

The whole *HTTPServer family appears to need some 
sort of unified rewrite, but it's difficult to see how that will 
happen.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 10:18

Message:
Logged In: YES 
user_id=6380

Looks good to me. Please check this in...

I think it's safe to check this into the 2.2 maintenance
branch as well.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-12-17 01:47

Message:
Logged In: YES 
user_id=250749

The patch file is missing.

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

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


From noreply@sourceforge.net  Wed Jan  8 15:33:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 07:33:11 -0800
Subject: [Patches] [ python-Patches-654910 ] Fix bug in IE/CGI [bug 427345]
Message-ID: <E18WICd-0005KA-00@sc8-sf-web1.sourceforge.net>

Patches item #654910, was opened at 2002-12-17 00:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=654910&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: Accepted
Priority: 4
Submitted By: Steve Holden (holdenweb)
>Assigned to: Steve Holden (holdenweb)
Summary: Fix bug in IE/CGI [bug 427345]

Initial Comment:
This patch fixes Unix (have_fork) and Windows 
(have_popen2 or have_popen3) CGI scripts to cope with 
Internet Explorer's "mozilla emulation", whereby it 
appears to send a couple extra bytes [CRLF?] at the 
end of requests when KeepAlive isn't in use.

While the bug is believed to only affect requests using 
method POST, the code is written to ignore extra bytes 
in any request triggering a CGI call on these platforms. It 
wasn't obvious how to apply similar fixes to the 
third, "other platform" branch.

The whole *HTTPServer family appears to need some 
sort of unified rewrite, but it's difficult to see how that will 
happen.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 16:18

Message:
Logged In: YES 
user_id=6380

Looks good to me. Please check this in...

I think it's safe to check this into the 2.2 maintenance
branch as well.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-12-17 07:47

Message:
Logged In: YES 
user_id=250749

The patch file is missing.

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

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


From noreply@sourceforge.net  Wed Jan  8 18:45:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 10:45:36 -0800
Subject: [Patches] [ python-Patches-664192 ] 661913: inconsistent error messages between string an unicod
Message-ID: <E18WLCq-0006j4-00@sc8-sf-web1.sourceforge.net>

Patches item #664192, was opened at 2003-01-08 05:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664192&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Nobody/Anonymous (nobody)
Summary: 661913: inconsistent error messages between string an unicod

Initial Comment:
'a'.index('b'):   substring not found in index
u'a'.index('b'): substring not found     (bah!)

same thing follows for rindex.

changed unicodeobject.c to return same error message as
what string returns.



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

Comment By: Inyeol Lee (inyeol)
Date: 2003-01-08 18:45

Message:
Logged In: YES 
user_id=595280

Hmm... I think the patch should be in the
opposite direction - leaving unicode message
as is and fix stringobject.c to make the
message the same as unicode. I've scanned
all the exception messages in string methods
and (r)index() is the only method which contains
method name in its exception message. For example,

>>> 'a'.split('')
ValueError: empty separator

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

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


From noreply@sourceforge.net  Wed Jan  8 19:00:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 11:00:09 -0800
Subject: [Patches] [ python-Patches-654910 ] Fix bug in IE/CGI [bug 427345]
Message-ID: <E18WLQv-0006aD-00@sc8-sf-web3.sourceforge.net>

Patches item #654910, was opened at 2002-12-16 18:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=654910&group_id=5470

Category: Library (Lib)
Group: None
>Status: Pending
Resolution: Accepted
Priority: 4
Submitted By: Steve Holden (holdenweb)
Assigned to: Steve Holden (holdenweb)
Summary: Fix bug in IE/CGI [bug 427345]

Initial Comment:
This patch fixes Unix (have_fork) and Windows 
(have_popen2 or have_popen3) CGI scripts to cope with 
Internet Explorer's "mozilla emulation", whereby it 
appears to send a couple extra bytes [CRLF?] at the 
end of requests when KeepAlive isn't in use.

While the bug is believed to only affect requests using 
method POST, the code is written to ignore extra bytes 
in any request triggering a CGI call on these platforms. It 
wasn't obvious how to apply similar fixes to the 
third, "other platform" branch.

The whole *HTTPServer family appears to need some 
sort of unified rewrite, but it's difficult to see how that will 
happen.


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

>Comment By: Steve Holden (holdenweb)
Date: 2003-01-08 14:00

Message:
Logged In: YES 
user_id=88157

Comitted today after review by MvL.

How do I check it into the maintenance branch?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 10:18

Message:
Logged In: YES 
user_id=6380

Looks good to me. Please check this in...

I think it's safe to check this into the 2.2 maintenance
branch as well.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-12-17 01:47

Message:
Logged In: YES 
user_id=250749

The patch file is missing.

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

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


From noreply@sourceforge.net  Wed Jan  8 19:03:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 11:03:07 -0800
Subject: [Patches] [ python-Patches-664320 ] Replace pop/push pairs in ceval.c
Message-ID: <E18WLTn-0006iB-00@sc8-sf-web3.sourceforge.net>

Patches item #664320, was opened at 2003-01-08 06:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Replace pop/push pairs in ceval.c

Initial Comment:
Paired PUSH() and POP() macros unnecessarily 
decrement and then re-increment the stack pointer.  
In these cases, indexed access to and from the stack 
is faster.

Saves the add 4 and sub 4 in the assembler code. 
Allows the compiler more freedom to optimize (by 
not overspecifying or creating sequential 
interdependencies). Lets the processor run more of 
the instructions in parallel (adjusting the index 
prevents parallel execution any move or other 
instruction that depends on the index).

I wouldn't begin to know how to time the savings 
here, but examining the  generated assembler shows 
that the code has improved.

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

Comment By: Tim Peters (tim_one)
Date: 2003-01-08 13:37

Message:
Logged In: YES 
user_id=31435

I haven't reviewed this in detail (and won't), but +1 on the 
idea -- these kinds of small code improvements may or may 
not yield immediate speedups, but reliably move things in 
the right direction over time, as they compound.  The parts 
of the patch I did stare at didn't suffer in clarity, so +1 all 
around.

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

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


From noreply@sourceforge.net  Wed Jan  8 19:05:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 11:05:45 -0800
Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest
Message-ID: <E18WLWL-0006oc-00@sc8-sf-web3.sourceforge.net>

Patches item #662807, was opened at 2003-01-05 21:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Port tests to unittest

Initial Comment:
This patch ports the three tests test_pow.py, 
test_charmapcodec.py and test_userdict.py to unittest.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-08 20:05

Message:
Logged In: YES 
user_id=89016

test_b1 and test_b2 are combined into test_builtin now

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 15:03

Message:
Logged In: YES 
user_id=6380

Two random suggestions:

- a blank line before each method, even trivial ones, even
the first one

- use assertEqual, not assertEquals

BTW, I see you've picked up on the convention that unit test
methods should not have doc strings. Good! (But they may
have comments.)

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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-07 17:37

Message:
Logged In: YES 
user_id=89016

test_b1.py has been ported too.

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

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-05 21:56

Message:
Logged In: YES 
user_id=89016

The patch is hard to read, so I'll upload all three test scripts.

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

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


From noreply@sourceforge.net  Wed Jan  8 18:37:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 10:37:08 -0800
Subject: [Patches] [ python-Patches-664320 ] Replace pop/push pairs in ceval.c
Message-ID: <E18WL4e-0006HR-00@sc8-sf-web1.sourceforge.net>

Patches item #664320, was opened at 2003-01-08 06:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Jeremy Hylton (jhylton)
Summary: Replace pop/push pairs in ceval.c

Initial Comment:
Paired PUSH() and POP() macros unnecessarily 
decrement and then re-increment the stack pointer.  
In these cases, indexed access to and from the stack 
is faster.

Saves the add 4 and sub 4 in the assembler code. 
Allows the compiler more freedom to optimize (by 
not overspecifying or creating sequential 
interdependencies). Lets the processor run more of 
the instructions in parallel (adjusting the index 
prevents parallel execution any move or other 
instruction that depends on the index).

I wouldn't begin to know how to time the savings 
here, but examining the  generated assembler shows 
that the code has improved.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-01-08 13:37

Message:
Logged In: YES 
user_id=31435

I haven't reviewed this in detail (and won't), but +1 on the 
idea -- these kinds of small code improvements may or may 
not yield immediate speedups, but reliably move things in 
the right direction over time, as they compound.  The parts 
of the patch I did stare at didn't suffer in clarity, so +1 all 
around.

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

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


From noreply@sourceforge.net  Wed Jan  8 19:35:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 11:35:54 -0800
Subject: [Patches] [ python-Patches-654910 ] Fix bug in IE/CGI [bug 427345]
Message-ID: <E18WLzW-0000Xp-00@sc8-sf-web1.sourceforge.net>

Patches item #654910, was opened at 2002-12-16 18:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=654910&group_id=5470

Category: Library (Lib)
Group: None
>Status: Open
Resolution: Accepted
Priority: 4
Submitted By: Steve Holden (holdenweb)
Assigned to: Steve Holden (holdenweb)
Summary: Fix bug in IE/CGI [bug 427345]

Initial Comment:
This patch fixes Unix (have_fork) and Windows 
(have_popen2 or have_popen3) CGI scripts to cope with 
Internet Explorer's "mozilla emulation", whereby it 
appears to send a couple extra bytes [CRLF?] at the 
end of requests when KeepAlive isn't in use.

While the bug is believed to only affect requests using 
method POST, the code is written to ignore extra bytes 
in any request triggering a CGI call on these platforms. It 
wasn't obvious how to apply similar fixes to the 
third, "other platform" branch.

The whole *HTTPServer family appears to need some 
sort of unified rewrite, but it's difficult to see how that will 
happen.


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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 14:35

Message:
Logged In: YES 
user_id=33168

You need to check out a version on the branch:

    cvs upd -r release22-maint CGIHTTPServer.py
 
Then merge in your last changes:

    cvs upd -j 1.29 -j 1.30 CGIHTTPServer.py

Then you should verify the changes were made correctly:

    cvs diff CGIHTTPServer.py

Then checkin as you would normally:

    cvs commit CGIHTTPServer.py

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

Comment By: Steve Holden (holdenweb)
Date: 2003-01-08 14:00

Message:
Logged In: YES 
user_id=88157

Comitted today after review by MvL.

How do I check it into the maintenance branch?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 10:18

Message:
Logged In: YES 
user_id=6380

Looks good to me. Please check this in...

I think it's safe to check this into the 2.2 maintenance
branch as well.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-12-17 01:47

Message:
Logged In: YES 
user_id=250749

The patch file is missing.

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

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


From noreply@sourceforge.net  Wed Jan  8 20:54:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 12:54:06 -0800
Subject: [Patches] [ python-Patches-661583 ] Remove old code from lib\os.py
Message-ID: <E18WNDC-0003kI-00@sc8-sf-web3.sourceforge.net>

Patches item #661583, was opened at 2003-01-03 13:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661583&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Andrew Wilkinson (andrew_j_w)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove old code from lib\os.py

Initial Comment:
os.py contains exec statements for NT and CE that are 
left over from Python 1.52b2.

They make it hard to statically anaylse python code os 
is such a core module.

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

>Comment By: Andrew Wilkinson (andrew_j_w)
Date: 2003-01-08 20:54

Message:
Logged In: YES 
user_id=295727

Just to make things a bit clearer...

In the standard module os there's a small amount of code (in 
the windows nt and ce sections) that uses an exec statement 
to load a single module. This was originally added in Python 
1.52b2 but was very soon made obsolete. The exec 
statement was left in however when it could quite easily be 
removed to make things much clearer.

This patch makes those changes and would be completely 
transparent to users of os.

The reason I ask for this is that I'm trying to statically anyalse 
Python code, but I code anyalse exec or eval and having it in 
such a core module, when it doesn't need to be there is 
making life difficult me.

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

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


From noreply@sourceforge.net  Wed Jan  8 21:08:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 13:08:08 -0800
Subject: [Patches] [ python-Patches-664192 ] 661913: inconsistent error messages between string an unicod
Message-ID: <E18WNQm-0004Qn-00@sc8-sf-web1.sourceforge.net>

Patches item #664192, was opened at 2003-01-08 00:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664192&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Nobody/Anonymous (nobody)
Summary: 661913: inconsistent error messages between string an unicod

Initial Comment:
'a'.index('b'):   substring not found in index
u'a'.index('b'): substring not found     (bah!)

same thing follows for rindex.

changed unicodeobject.c to return same error message as
what string returns.



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

>Comment By: Christopher Blunck (blunck2)
Date: 2003-01-08 16:08

Message:
Logged In: YES 
user_id=531881

Probably a good idea inyeol.  Will post a follow-up patch
tonight.  Thanks.

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

Comment By: Inyeol Lee (inyeol)
Date: 2003-01-08 13:45

Message:
Logged In: YES 
user_id=595280

Hmm... I think the patch should be in the
opposite direction - leaving unicode message
as is and fix stringobject.c to make the
message the same as unicode. I've scanned
all the exception messages in string methods
and (r)index() is the only method which contains
method name in its exception message. For example,

>>> 'a'.split('')
ValueError: empty separator

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

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


From noreply@sourceforge.net  Wed Jan  8 21:10:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 13:10:19 -0800
Subject: [Patches] [ python-Patches-661583 ] Remove old code from lib\os.py
Message-ID: <E18WNSt-0003TJ-00@sc8-sf-web2.sourceforge.net>

Patches item #661583, was opened at 2003-01-03 08:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661583&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Andrew Wilkinson (andrew_j_w)
>Assigned to: Tim Peters (tim_one)
Summary: Remove old code from lib\os.py

Initial Comment:
os.py contains exec statements for NT and CE that are 
left over from Python 1.52b2.

They make it hard to statically anaylse python code os 
is such a core module.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-01-08 16:10

Message:
Logged In: YES 
user_id=31435

Assigned to me.

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

Comment By: Andrew Wilkinson (andrew_j_w)
Date: 2003-01-08 15:54

Message:
Logged In: YES 
user_id=295727

Just to make things a bit clearer...

In the standard module os there's a small amount of code (in 
the windows nt and ce sections) that uses an exec statement 
to load a single module. This was originally added in Python 
1.52b2 but was very soon made obsolete. The exec 
statement was left in however when it could quite easily be 
removed to make things much clearer.

This patch makes those changes and would be completely 
transparent to users of os.

The reason I ask for this is that I'm trying to statically anyalse 
Python code, but I code anyalse exec or eval and having it in 
such a core module, when it doesn't need to be there is 
making life difficult me.

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

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


From noreply@sourceforge.net  Wed Jan  8 21:23:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 13:23:34 -0800
Subject: [Patches] [ python-Patches-661583 ] Remove old code from lib\os.py
Message-ID: <E18WNfi-0003wr-00@sc8-sf-web4.sourceforge.net>

Patches item #661583, was opened at 2003-01-03 08:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661583&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Andrew Wilkinson (andrew_j_w)
Assigned to: Tim Peters (tim_one)
Summary: Remove old code from lib\os.py

Initial Comment:
os.py contains exec statements for NT and CE that are 
left over from Python 1.52b2.

They make it hard to statically anaylse python code os 
is such a core module.

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

>Comment By: Tim Peters (tim_one)
Date: 2003-01-08 16:23

Message:
Logged In: YES 
user_id=31435

Thanks, Andrew -- that code was bizarre.  The patch has 
been checkin in, as Lib/os.py rev 1.65, for 2.3a2.

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

Comment By: Tim Peters (tim_one)
Date: 2003-01-08 16:10

Message:
Logged In: YES 
user_id=31435

Assigned to me.

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

Comment By: Andrew Wilkinson (andrew_j_w)
Date: 2003-01-08 15:54

Message:
Logged In: YES 
user_id=295727

Just to make things a bit clearer...

In the standard module os there's a small amount of code (in 
the windows nt and ce sections) that uses an exec statement 
to load a single module. This was originally added in Python 
1.52b2 but was very soon made obsolete. The exec 
statement was left in however when it could quite easily be 
removed to make things much clearer.

This patch makes those changes and would be completely 
transparent to users of os.

The reason I ask for this is that I'm trying to statically anyalse 
Python code, but I code anyalse exec or eval and having it in 
such a core module, when it doesn't need to be there is 
making life difficult me.

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

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


From noreply@sourceforge.net  Thu Jan  9 03:33:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 19:33:32 -0800
Subject: [Patches] [ python-Patches-664320 ] Replace pop/push pairs in ceval.c
Message-ID: <E18WTRk-0001GK-00@sc8-sf-web2.sourceforge.net>

Patches item #664320, was opened at 2003-01-08 06:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Replace pop/push pairs in ceval.c

Initial Comment:
Paired PUSH() and POP() macros unnecessarily 
decrement and then re-increment the stack pointer.  
In these cases, indexed access to and from the stack 
is faster.

Saves the add 4 and sub 4 in the assembler code. 
Allows the compiler more freedom to optimize (by 
not overspecifying or creating sequential 
interdependencies). Lets the processor run more of 
the instructions in parallel (adjusting the index 
prevents parallel execution any move or other 
instruction that depends on the index).

I wouldn't begin to know how to time the savings 
here, but examining the  generated assembler shows 
that the code has improved.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 22:33

Message:
Logged In: YES 
user_id=33168

I'm reviewing this patch now and have a question.  There is
code to handle DUP_TOPX for values of X == 4 and 5.  I don't
see how this can be generated.  I greped the code for
DUP_TOPX and only found values of 2 and 3.  Should the code
for 4 and 5 be removed?  Am I missing something?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-08 13:37

Message:
Logged In: YES 
user_id=31435

I haven't reviewed this in detail (and won't), but +1 on the 
idea -- these kinds of small code improvements may or may 
not yield immediate speedups, but reliably move things in 
the right direction over time, as they compound.  The parts 
of the patch I did stare at didn't suffer in clarity, so +1 all 
around.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470


From noreply@sourceforge.net  Thu Jan  9 03:54:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 19:54:02 -0800
Subject: [Patches] [ python-Patches-664320 ] Replace pop/push pairs in ceval.c
Message-ID: <E18WTla-0001fH-00@sc8-sf-web1.sourceforge.net>

Patches item #664320, was opened at 2003-01-08 06:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Replace pop/push pairs in ceval.c

Initial Comment:
Paired PUSH() and POP() macros unnecessarily 
decrement and then re-increment the stack pointer.  
In these cases, indexed access to and from the stack 
is faster.

Saves the add 4 and sub 4 in the assembler code. 
Allows the compiler more freedom to optimize (by 
not overspecifying or creating sequential 
interdependencies). Lets the processor run more of 
the instructions in parallel (adjusting the index 
prevents parallel execution any move or other 
instruction that depends on the index).

I wouldn't begin to know how to time the savings 
here, but examining the  generated assembler shows 
that the code has improved.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 22:54

Message:
Logged In: YES 
user_id=33168

One thing to note, if LLTRACE is defined, you lose that
capability since PUSH/POP are not called that frequently.  I
don't know how useful LLTRACE is and I don't care about this
"loss."  mwh may have used it recently, so it may be good to
get his opinion.

I reviewed patch in detail and didn't find any problems.  I
ran the regression suite on Linux without problems.  I also
ran pychecker over the stdlib, that sometimes provokes weird
bugs, no problems there either. :-)

If anything, I like the code better after this patch. 
Definitely +1.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 22:33

Message:
Logged In: YES 
user_id=33168

I'm reviewing this patch now and have a question.  There is
code to handle DUP_TOPX for values of X == 4 and 5.  I don't
see how this can be generated.  I greped the code for
DUP_TOPX and only found values of 2 and 3.  Should the code
for 4 and 5 be removed?  Am I missing something?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-08 13:37

Message:
Logged In: YES 
user_id=31435

I haven't reviewed this in detail (and won't), but +1 on the 
idea -- these kinds of small code improvements may or may 
not yield immediate speedups, but reliably move things in 
the right direction over time, as they compound.  The parts 
of the patch I did stare at didn't suffer in clarity, so +1 all 
around.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470


From noreply@sourceforge.net  Thu Jan  9 04:29:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 20:29:44 -0800
Subject: [Patches] [ python-Patches-664320 ] Replace pop/push pairs in ceval.c
Message-ID: <E18WUK8-00020a-00@sc8-sf-web4.sourceforge.net>

Patches item #664320, was opened at 2003-01-08 06:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Replace pop/push pairs in ceval.c

Initial Comment:
Paired PUSH() and POP() macros unnecessarily 
decrement and then re-increment the stack pointer.  
In these cases, indexed access to and from the stack 
is faster.

Saves the add 4 and sub 4 in the assembler code. 
Allows the compiler more freedom to optimize (by 
not overspecifying or creating sequential 
interdependencies). Lets the processor run more of 
the instructions in parallel (adjusting the index 
prevents parallel execution any move or other 
instruction that depends on the index).

I wouldn't begin to know how to time the savings 
here, but examining the  generated assembler shows 
that the code has improved.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-08 23:29

Message:
Logged In: YES 
user_id=80475

If you don't mind a little more code review, I've attached an 
extended version of the patch that does the same thing for 
other op codes (only where it could be done cleanly).  The 
goal was to use direct access as much as possible and 
have at most one adjustment to the stacklevel for each op 
code.

LLTRACE looks like a relic from 1992.  Will contact  mwh 
to ask whether it can completely eliminated.

Will leave DUP_TOPX able to handle x=4 or x=5.  It's 
harmless enough and I have no way of being sure that 
something somewhere hasn't generated bytecode that 
relies on it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 22:54

Message:
Logged In: YES 
user_id=33168

One thing to note, if LLTRACE is defined, you lose that
capability since PUSH/POP are not called that frequently.  I
don't know how useful LLTRACE is and I don't care about this
"loss."  mwh may have used it recently, so it may be good to
get his opinion.

I reviewed patch in detail and didn't find any problems.  I
ran the regression suite on Linux without problems.  I also
ran pychecker over the stdlib, that sometimes provokes weird
bugs, no problems there either. :-)

If anything, I like the code better after this patch. 
Definitely +1.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 22:33

Message:
Logged In: YES 
user_id=33168

I'm reviewing this patch now and have a question.  There is
code to handle DUP_TOPX for values of X == 4 and 5.  I don't
see how this can be generated.  I greped the code for
DUP_TOPX and only found values of 2 and 3.  Should the code
for 4 and 5 be removed?  Am I missing something?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-08 13:37

Message:
Logged In: YES 
user_id=31435

I haven't reviewed this in detail (and won't), but +1 on the 
idea -- these kinds of small code improvements may or may 
not yield immediate speedups, but reliably move things in 
the right direction over time, as they compound.  The parts 
of the patch I did stare at didn't suffer in clarity, so +1 all 
around.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470


From noreply@sourceforge.net  Thu Jan  9 04:59:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 08 Jan 2003 20:59:26 -0800
Subject: [Patches] [ python-Patches-664320 ] Replace pop/push pairs in ceval.c
Message-ID: <E18WUms-0003qs-00@sc8-sf-web1.sourceforge.net>

Patches item #664320, was opened at 2003-01-08 06:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Replace pop/push pairs in ceval.c

Initial Comment:
Paired PUSH() and POP() macros unnecessarily 
decrement and then re-increment the stack pointer.  
In these cases, indexed access to and from the stack 
is faster.

Saves the add 4 and sub 4 in the assembler code. 
Allows the compiler more freedom to optimize (by 
not overspecifying or creating sequential 
interdependencies). Lets the processor run more of 
the instructions in parallel (adjusting the index 
prevents parallel execution any move or other 
instruction that depends on the index).

I wouldn't begin to know how to time the savings 
here, but examining the  generated assembler shows 
that the code has improved.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 23:59

Message:
Logged In: YES 
user_id=33168

Everything looks ok, except I'm not sure about the hunk in
GET_ITER.  It looks like v is left on the stack if x ==
NULL.  This is a change from the current version.  Taking a
look again, this seems to affect UNARY_NOT also.

I think LLTRACE is old.  Here's some mail where mwh talks
about it when he got rid of SET_LINENO. 
http://mail.python.org/pipermail/python-dev/2002-August/027219.html

I agree that you shouldn't change DUP_TOPX in this patch. 
It's a separate issue.  I think it might be good to remove
separately, to reduce the size of code in the eval_frame
loop.  But it's just thinking.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-08 23:29

Message:
Logged In: YES 
user_id=80475

If you don't mind a little more code review, I've attached an 
extended version of the patch that does the same thing for 
other op codes (only where it could be done cleanly).  The 
goal was to use direct access as much as possible and 
have at most one adjustment to the stacklevel for each op 
code.

LLTRACE looks like a relic from 1992.  Will contact  mwh 
to ask whether it can completely eliminated.

Will leave DUP_TOPX able to handle x=4 or x=5.  It's 
harmless enough and I have no way of being sure that 
something somewhere hasn't generated bytecode that 
relies on it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 22:54

Message:
Logged In: YES 
user_id=33168

One thing to note, if LLTRACE is defined, you lose that
capability since PUSH/POP are not called that frequently.  I
don't know how useful LLTRACE is and I don't care about this
"loss."  mwh may have used it recently, so it may be good to
get his opinion.

I reviewed patch in detail and didn't find any problems.  I
ran the regression suite on Linux without problems.  I also
ran pychecker over the stdlib, that sometimes provokes weird
bugs, no problems there either. :-)

If anything, I like the code better after this patch. 
Definitely +1.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 22:33

Message:
Logged In: YES 
user_id=33168

I'm reviewing this patch now and have a question.  There is
code to handle DUP_TOPX for values of X == 4 and 5.  I don't
see how this can be generated.  I greped the code for
DUP_TOPX and only found values of 2 and 3.  Should the code
for 4 and 5 be removed?  Am I missing something?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-08 13:37

Message:
Logged In: YES 
user_id=31435

I haven't reviewed this in detail (and won't), but +1 on the 
idea -- these kinds of small code improvements may or may 
not yield immediate speedups, but reliably move things in 
the right direction over time, as they compound.  The parts 
of the patch I did stare at didn't suffer in clarity, so +1 all 
around.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470


From noreply@sourceforge.net  Thu Jan  9 10:41:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 09 Jan 2003 02:41:25 -0800
Subject: [Patches] [ python-Patches-654910 ] Fix bug in IE/CGI [bug 427345]
Message-ID: <E18Wa7p-0005Sa-00@sc8-sf-web2.sourceforge.net>

Patches item #654910, was opened at 2002-12-17 00:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=654910&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: Accepted
Priority: 4
Submitted By: Steve Holden (holdenweb)
Assigned to: Steve Holden (holdenweb)
Summary: Fix bug in IE/CGI [bug 427345]

Initial Comment:
This patch fixes Unix (have_fork) and Windows 
(have_popen2 or have_popen3) CGI scripts to cope with 
Internet Explorer's "mozilla emulation", whereby it 
appears to send a couple extra bytes [CRLF?] at the 
end of requests when KeepAlive isn't in use.

While the bug is believed to only affect requests using 
method POST, the code is written to ignore extra bytes 
in any request triggering a CGI call on these platforms. It 
wasn't obvious how to apply similar fixes to the 
third, "other platform" branch.

The whole *HTTPServer family appears to need some 
sort of unified rewrite, but it's difficult to see how that will 
happen.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-09 11:41

Message:
Logged In: YES 
user_id=21627

I usually replace the cvs join with applying the original
patch the the branch sandbox.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 20:35

Message:
Logged In: YES 
user_id=33168

You need to check out a version on the branch:

    cvs upd -r release22-maint CGIHTTPServer.py
 
Then merge in your last changes:

    cvs upd -j 1.29 -j 1.30 CGIHTTPServer.py

Then you should verify the changes were made correctly:

    cvs diff CGIHTTPServer.py

Then checkin as you would normally:

    cvs commit CGIHTTPServer.py

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2003-01-08 20:00

Message:
Logged In: YES 
user_id=88157

Comitted today after review by MvL.

How do I check it into the maintenance branch?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 16:18

Message:
Logged In: YES 
user_id=6380

Looks good to me. Please check this in...

I think it's safe to check this into the 2.2 maintenance
branch as well.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-12-17 07:47

Message:
Logged In: YES 
user_id=250749

The patch file is missing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=654910&group_id=5470


From noreply@sourceforge.net  Thu Jan  9 14:07:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 09 Jan 2003 06:07:09 -0800
Subject: [Patches] [ python-Patches-654910 ] Fix bug in IE/CGI [bug 427345]
Message-ID: <E18WdKv-0005Hh-00@sc8-sf-web2.sourceforge.net>

Patches item #654910, was opened at 2002-12-16 18:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=654910&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
Resolution: Accepted
Priority: 4
Submitted By: Steve Holden (holdenweb)
Assigned to: Steve Holden (holdenweb)
Summary: Fix bug in IE/CGI [bug 427345]

Initial Comment:
This patch fixes Unix (have_fork) and Windows 
(have_popen2 or have_popen3) CGI scripts to cope with 
Internet Explorer's "mozilla emulation", whereby it 
appears to send a couple extra bytes [CRLF?] at the 
end of requests when KeepAlive isn't in use.

While the bug is believed to only affect requests using 
method POST, the code is written to ignore extra bytes 
in any request triggering a CGI call on these platforms. It 
wasn't obvious how to apply similar fixes to the 
third, "other platform" branch.

The whole *HTTPServer family appears to need some 
sort of unified rewrite, but it's difficult to see how that will 
happen.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-09 09:07

Message:
Logged In: YES 
user_id=33168

Closing this patch, since it was apparantly checked in as
1.30 and 1.20.8.4.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-09 05:41

Message:
Logged In: YES 
user_id=21627

I usually replace the cvs join with applying the original
patch the the branch sandbox.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 14:35

Message:
Logged In: YES 
user_id=33168

You need to check out a version on the branch:

    cvs upd -r release22-maint CGIHTTPServer.py
 
Then merge in your last changes:

    cvs upd -j 1.29 -j 1.30 CGIHTTPServer.py

Then you should verify the changes were made correctly:

    cvs diff CGIHTTPServer.py

Then checkin as you would normally:

    cvs commit CGIHTTPServer.py

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2003-01-08 14:00

Message:
Logged In: YES 
user_id=88157

Comitted today after review by MvL.

How do I check it into the maintenance branch?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 10:18

Message:
Logged In: YES 
user_id=6380

Looks good to me. Please check this in...

I think it's safe to check this into the 2.2 maintenance
branch as well.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2002-12-17 01:47

Message:
Logged In: YES 
user_id=250749

The patch file is missing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=654910&group_id=5470


From noreply@sourceforge.net  Thu Jan  9 15:28:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 09 Jan 2003 07:28:07 -0800
Subject: [Patches] [ python-Patches-664320 ] Replace pop/push pairs in ceval.c
Message-ID: <E18WebH-0001GV-00@sc8-sf-web2.sourceforge.net>

Patches item #664320, was opened at 2003-01-08 06:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Replace pop/push pairs in ceval.c

Initial Comment:
Paired PUSH() and POP() macros unnecessarily 
decrement and then re-increment the stack pointer.  
In these cases, indexed access to and from the stack 
is faster.

Saves the add 4 and sub 4 in the assembler code. 
Allows the compiler more freedom to optimize (by 
not overspecifying or creating sequential 
interdependencies). Lets the processor run more of 
the instructions in parallel (adjusting the index 
prevents parallel execution any move or other 
instruction that depends on the index).

I wouldn't begin to know how to time the savings 
here, but examining the  generated assembler shows 
that the code has improved.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-09 10:28

Message:
Logged In: YES 
user_id=80475

Added a final POP() to GET_ITER and UNARY_NOT to make 
sure v comes off the stack upon an error exit.

Added STACKADJ to the LLTRACE logic.  This maintains its 
current definition of triggering a trace event whenever the 
stacklevel changes.  The new patch differs from the old 
only it that it makes fewer level changes.

Thank you for the thorough review. 

Committing as ceval.c 2.343
Marking as closed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 23:59

Message:
Logged In: YES 
user_id=33168

Everything looks ok, except I'm not sure about the hunk in
GET_ITER.  It looks like v is left on the stack if x ==
NULL.  This is a change from the current version.  Taking a
look again, this seems to affect UNARY_NOT also.

I think LLTRACE is old.  Here's some mail where mwh talks
about it when he got rid of SET_LINENO. 
http://mail.python.org/pipermail/python-dev/2002-August/027219.html

I agree that you shouldn't change DUP_TOPX in this patch. 
It's a separate issue.  I think it might be good to remove
separately, to reduce the size of code in the eval_frame
loop.  But it's just thinking.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-08 23:29

Message:
Logged In: YES 
user_id=80475

If you don't mind a little more code review, I've attached an 
extended version of the patch that does the same thing for 
other op codes (only where it could be done cleanly).  The 
goal was to use direct access as much as possible and 
have at most one adjustment to the stacklevel for each op 
code.

LLTRACE looks like a relic from 1992.  Will contact  mwh 
to ask whether it can completely eliminated.

Will leave DUP_TOPX able to handle x=4 or x=5.  It's 
harmless enough and I have no way of being sure that 
something somewhere hasn't generated bytecode that 
relies on it.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 22:54

Message:
Logged In: YES 
user_id=33168

One thing to note, if LLTRACE is defined, you lose that
capability since PUSH/POP are not called that frequently.  I
don't know how useful LLTRACE is and I don't care about this
"loss."  mwh may have used it recently, so it may be good to
get his opinion.

I reviewed patch in detail and didn't find any problems.  I
ran the regression suite on Linux without problems.  I also
ran pychecker over the stdlib, that sometimes provokes weird
bugs, no problems there either. :-)

If anything, I like the code better after this patch. 
Definitely +1.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-08 22:33

Message:
Logged In: YES 
user_id=33168

I'm reviewing this patch now and have a question.  There is
code to handle DUP_TOPX for values of X == 4 and 5.  I don't
see how this can be generated.  I greped the code for
DUP_TOPX and only found values of 2 and 3.  Should the code
for 4 and 5 be removed?  Am I missing something?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-08 13:37

Message:
Logged In: YES 
user_id=31435

I haven't reviewed this in detail (and won't), but +1 on the 
idea -- these kinds of small code improvements may or may 
not yield immediate speedups, but reliably move things in 
the right direction over time, as they compound.  The parts 
of the patch I did stare at didn't suffer in clarity, so +1 all 
around.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664320&group_id=5470


From noreply@sourceforge.net  Thu Jan  9 15:32:15 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 09 Jan 2003 07:32:15 -0800
Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest
Message-ID: <E18WefH-0001W9-00@sc8-sf-web2.sourceforge.net>

Patches item #662807, was opened at 2003-01-05 15:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Port tests to unittest

Initial Comment:
This patch ports the three tests test_pow.py, 
test_charmapcodec.py and test_userdict.py to unittest.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-08 14:05

Message:
Logged In: YES 
user_id=89016

test_b1 and test_b2 are combined into test_builtin now

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 09:03

Message:
Logged In: YES 
user_id=6380

Two random suggestions:

- a blank line before each method, even trivial ones, even
the first one

- use assertEqual, not assertEquals

BTW, I see you've picked up on the convention that unit test
methods should not have doc strings. Good! (But they may
have comments.)

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-07 11:37

Message:
Logged In: YES 
user_id=89016

test_b1.py has been ported too.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-05 15:56

Message:
Logged In: YES 
user_id=89016

The patch is hard to read, so I'll upload all three test scripts.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 02:44:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 09 Jan 2003 18:44:19 -0800
Subject: [Patches] [ python-Patches-665458 ] Crash in binascii_a2b_uu on corrupt data
Message-ID: <E18Wp9f-0007qY-00@sc8-sf-web2.sourceforge.net>

Patches item #665458, was opened at 2003-01-10 03:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665458&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Scharf (scharf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash in binascii_a2b_uu on corrupt data

Initial Comment:
When I unpacked 50 gigabytes of randomly downloaded 
usenet binary news posts python crashed (randomly) on 
windows. After long tracking (I did'nt have a debug 
version) I found the problem in binascii_a2b_uu:

When reading the input data, the boundaries of the input 
sting are not checked. With corrupted uuencoded data 
(the first bite gives the length of the encoded string), the 
function reads out of bounds of the input string. That is 
not a problem (in most cases) but sometimes (it 
happened typicallyafter 20-30 gibagytes of parsed data) 
the allocated string might be at the end of a 
memory 'segment' and there is no string after the 
allocated string. And that causes a crash.

I have attached a patch to solve the problem. (Python 
2.2.2)

Michael

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665458&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 08:12:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 00:12:45 -0800
Subject: [Patches] [ python-Patches-664183 ] 664044: 2.2.6.2 String formatting operations
Message-ID: <E18WuHV-00008h-00@sc8-sf-web2.sourceforge.net>

Patches item #664183, was opened at 2003-01-08 00:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664183&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: 664044: 2.2.6.2 String formatting operations

Initial Comment:
Documentation states that format % object returns a
Unicode string if either format or object are unicode.
 However, in the conversion table, the documentation
for the conversion "s" states that a String will be
returned.  It does not state that a unicode String will
be returned if the formatter is u"s" or if the object
being converted is unicode.  

I added a note to clarify the conversion table.  It
simply states that in the event of a unicode formatter
or a unicode string being converted, a unicode string
(not a regular string) will be returned.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664183&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 09:51:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 01:51:34 -0800
Subject: [Patches] [ python-Patches-664192 ] 661913: inconsistent error messages between string an unicod
Message-ID: <E18Wvp8-0001hW-00@sc8-sf-web3.sourceforge.net>

Patches item #664192, was opened at 2003-01-08 00:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664192&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: 661913: inconsistent error messages between string an unicod

Initial Comment:
'a'.index('b'):   substring not found in index
u'a'.index('b'): substring not found     (bah!)

same thing follows for rindex.

changed unicodeobject.c to return same error message as
what string returns.



----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-01-08 16:08

Message:
Logged In: YES 
user_id=531881

Probably a good idea inyeol.  Will post a follow-up patch
tonight.  Thanks.

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2003-01-08 13:45

Message:
Logged In: YES 
user_id=595280

Hmm... I think the patch should be in the
opposite direction - leaving unicode message
as is and fix stringobject.c to make the
message the same as unicode. I've scanned
all the exception messages in string methods
and (r)index() is the only method which contains
method name in its exception message. For example,

>>> 'a'.split('')
ValueError: empty separator

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664192&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 14:24:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 06:24:52 -0800
Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname
Message-ID: <E18X05c-0004O4-00@sc8-sf-web1.sourceforge.net>

Patches item #664376, was opened at 2003-01-08 14:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470

Category: None
Group: None
>Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Nobody/Anonymous (nobody)
Summary: sys.path[0] should contain absolute pathname

Initial Comment:
This patch changes sys.path[0] to contain an absolute 
instead of a relative pathname.

See python-dev thread starting here:
http://mail.python.org/pipermail/python-dev/2003-
January/031896.html

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-01-10 15:24

Message:
Logged In: YES 
user_id=11105

I believe this problem should be fixed also on systems other
than Windows, or the checkin should be reverted again.

I've prepared a patch based on an idea of Skip Montanaro,
who pointed my to the realpath() function.
It is tested on a SuSE 7.0 Linux system, but I don't know
which #ifdef I have to se around this code. See the patch
for details.

Reopened and unassigned for review.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 16:02

Message:
Logged In: YES 
user_id=11105

Checked in as sysmodule.c, rev 2.112.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 15:00

Message:
Logged In: YES 
user_id=6380

Feel free to check this in.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 14:31

Message:
Logged In: YES 
user_id=11105

The attached patch (sysmodule.diff) fixes the problem on 
Windows - that's the only system where I can test it.

It leaves sys.argv alone and only changes sys.path[0] to an 
absolute pathname.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 16:53:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 08:53:32 -0800
Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest
Message-ID: <E18X2PU-00049s-00@sc8-sf-web3.sourceforge.net>

Patches item #662807, was opened at 2003-01-05 21:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Port tests to unittest

Initial Comment:
This patch ports the three tests test_pow.py, 
test_charmapcodec.py and test_userdict.py to unittest.

----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-10 17:53

Message:
Logged In: YES 
user_id=89016

test_builtin.py is now updated to test more error
situations. This increases the coverage of bltinmodule.c
from 75.13% to 92.20%, and it actually revealed one or two
potential bugs:
http://www.python.org/sf/665761 and
http://www.python.org/sf/665835

I'm not 100% sure that test_intern() and test_execfile() do
the right thing.

I'm not sure, whether the test script should check for
undocumented implementation artefacts, like:

a = 1
self.assert_(min(a, 1L) is a)

but in this way at least we get notified if something is
changed unintentionally.


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-08 20:05

Message:
Logged In: YES 
user_id=89016

test_b1 and test_b2 are combined into test_builtin now

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 15:03

Message:
Logged In: YES 
user_id=6380

Two random suggestions:

- a blank line before each method, even trivial ones, even
the first one

- use assertEqual, not assertEquals

BTW, I see you've picked up on the convention that unit test
methods should not have doc strings. Good! (But they may
have comments.)

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-07 17:37

Message:
Logged In: YES 
user_id=89016

test_b1.py has been ported too.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-05 21:56

Message:
Logged In: YES 
user_id=89016

The patch is hard to read, so I'll upload all three test scripts.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 17:03:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 09:03:00 -0800
Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest
Message-ID: <E18X2Ye-0005Dv-00@sc8-sf-web2.sourceforge.net>

Patches item #662807, was opened at 2003-01-05 15:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Port tests to unittest

Initial Comment:
This patch ports the three tests test_pow.py, 
test_charmapcodec.py and test_userdict.py to unittest.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-10 12:03

Message:
Logged In: YES 
user_id=80475

Good to hear the news on increasing the coverage.

In general, don't do tests that hardwire implementation 
details.  Test it if it is a documented variable,  exposed 
through __all__, is a key constact (like the magic numbers 
in random.py), or a variable that a module user is likely to 
be relying upon.  Otherwise, no -- it should be possible to 
improve an implementation without crashing the suite.

I'll try to review a few of these over the next few days.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-10 11:53

Message:
Logged In: YES 
user_id=89016

test_builtin.py is now updated to test more error
situations. This increases the coverage of bltinmodule.c
from 75.13% to 92.20%, and it actually revealed one or two
potential bugs:
http://www.python.org/sf/665761 and
http://www.python.org/sf/665835

I'm not 100% sure that test_intern() and test_execfile() do
the right thing.

I'm not sure, whether the test script should check for
undocumented implementation artefacts, like:

a = 1
self.assert_(min(a, 1L) is a)

but in this way at least we get notified if something is
changed unintentionally.


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-08 14:05

Message:
Logged In: YES 
user_id=89016

test_b1 and test_b2 are combined into test_builtin now

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 09:03

Message:
Logged In: YES 
user_id=6380

Two random suggestions:

- a blank line before each method, even trivial ones, even
the first one

- use assertEqual, not assertEquals

BTW, I see you've picked up on the convention that unit test
methods should not have doc strings. Good! (But they may
have comments.)

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-07 11:37

Message:
Logged In: YES 
user_id=89016

test_b1.py has been ported too.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-05 15:56

Message:
Logged In: YES 
user_id=89016

The patch is hard to read, so I'll upload all three test scripts.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 17:17:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 09:17:07 -0800
Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest
Message-ID: <E18X2mJ-0005Jc-00@sc8-sf-web3.sourceforge.net>

Patches item #662807, was opened at 2003-01-05 21:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Port tests to unittest

Initial Comment:
This patch ports the three tests test_pow.py, 
test_charmapcodec.py and test_userdict.py to unittest.

----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-10 18:17

Message:
Logged In: YES 
user_id=89016

> In general, don't do tests that hardwire implementation 
details

So should we remove
self.assertEquals(reduce(42, "1"), "1")
self.assertEquals(reduce(42, "", "1"), "1")
from test_filter?

BTW, you should look at test_builtin first, as the others
are still simply ports to PyUnit.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-10 18:03

Message:
Logged In: YES 
user_id=80475

Good to hear the news on increasing the coverage.

In general, don't do tests that hardwire implementation 
details.  Test it if it is a documented variable,  exposed 
through __all__, is a key constact (like the magic numbers 
in random.py), or a variable that a module user is likely to 
be relying upon.  Otherwise, no -- it should be possible to 
improve an implementation without crashing the suite.

I'll try to review a few of these over the next few days.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-10 17:53

Message:
Logged In: YES 
user_id=89016

test_builtin.py is now updated to test more error
situations. This increases the coverage of bltinmodule.c
from 75.13% to 92.20%, and it actually revealed one or two
potential bugs:
http://www.python.org/sf/665761 and
http://www.python.org/sf/665835

I'm not 100% sure that test_intern() and test_execfile() do
the right thing.

I'm not sure, whether the test script should check for
undocumented implementation artefacts, like:

a = 1
self.assert_(min(a, 1L) is a)

but in this way at least we get notified if something is
changed unintentionally.


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-08 20:05

Message:
Logged In: YES 
user_id=89016

test_b1 and test_b2 are combined into test_builtin now

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 15:03

Message:
Logged In: YES 
user_id=6380

Two random suggestions:

- a blank line before each method, even trivial ones, even
the first one

- use assertEqual, not assertEquals

BTW, I see you've picked up on the convention that unit test
methods should not have doc strings. Good! (But they may
have comments.)

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-07 17:37

Message:
Logged In: YES 
user_id=89016

test_b1.py has been ported too.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-05 21:56

Message:
Logged In: YES 
user_id=89016

The patch is hard to read, so I'll upload all three test scripts.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 19:03:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 11:03:55 -0800
Subject: [Patches] [ python-Patches-665913 ] Fix mmap module core dump with unix
Message-ID: <E18X4Rf-0002iG-00@sc8-sf-web4.sourceforge.net>

Patches item #665913, was opened at 2003-01-10 14:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665913&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Clay Spence (cspence)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix mmap module core dump with unix

Initial Comment:
Calling the close method of an mmap object more than
once would cause a segmentation fault for me (python
2.2.2, compiled with Sun's Forte compilers, though I
doubt that matters, Solaris 2.8 on an ultra-sparc). 
The following code would do it reliably:

"""Demonstrate mmap bug?"""

import os
f=open('junk', 'w')
f.write(2**24 * 'a') # Arbitrary character
f.close()
s = os.stat('junk')    
s.st_size

from mmap import *
f = open('junk')
mf = mmap(f.fileno(), 2**24, access=ACCESS_READ)
print mf[0], mf[2**23]
mf.close()
mf.close()

The problem seems to be that mmap_close_method does an
munmap of the data and then sets it to NULL without
checking first whether the data pointer is already
NULL.  The windows part already checks this.  (Please
excuse me if I mess up the protocol for suggesting
patches.)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665913&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 20:22:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 12:22:59 -0800
Subject: [Patches] [ python-Patches-665913 ] Fix mmap module core dump with unix
Message-ID: <E18X5gB-00043o-00@sc8-sf-web1.sourceforge.net>

Patches item #665913, was opened at 2003-01-10 14:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665913&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Clay Spence (cspence)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Fix mmap module core dump with unix

Initial Comment:
Calling the close method of an mmap object more than
once would cause a segmentation fault for me (python
2.2.2, compiled with Sun's Forte compilers, though I
doubt that matters, Solaris 2.8 on an ultra-sparc). 
The following code would do it reliably:

"""Demonstrate mmap bug?"""

import os
f=open('junk', 'w')
f.write(2**24 * 'a') # Arbitrary character
f.close()
s = os.stat('junk')    
s.st_size

from mmap import *
f = open('junk')
mf = mmap(f.fileno(), 2**24, access=ACCESS_READ)
print mf[0], mf[2**23]
mf.close()
mf.close()

The problem seems to be that mmap_close_method does an
munmap of the data and then sets it to NULL without
checking first whether the data pointer is already
NULL.  The windows part already checks this.  (Please
excuse me if I mess up the protocol for suggesting
patches.)


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-10 15:22

Message:
Logged In: YES 
user_id=33168

There's no patch attached.  I think I can guess what it
would look like though. :-)  This code works on linux, but I
was able to provoke the problem on Solaris.

I suspect this problem affects 2.2.2 as well.  Assigning to
me, I'll fix, add a test, and NEWS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665913&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 20:36:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 12:36:53 -0800
Subject: [Patches] [ python-Patches-665913 ] Fix mmap module core dump with unix
Message-ID: <E18X5td-0004n6-00@sc8-sf-web1.sourceforge.net>

Patches item #665913, was opened at 2003-01-10 14:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665913&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Clay Spence (cspence)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Fix mmap module core dump with unix

Initial Comment:
Calling the close method of an mmap object more than
once would cause a segmentation fault for me (python
2.2.2, compiled with Sun's Forte compilers, though I
doubt that matters, Solaris 2.8 on an ultra-sparc). 
The following code would do it reliably:

"""Demonstrate mmap bug?"""

import os
f=open('junk', 'w')
f.write(2**24 * 'a') # Arbitrary character
f.close()
s = os.stat('junk')    
s.st_size

from mmap import *
f = open('junk')
mf = mmap(f.fileno(), 2**24, access=ACCESS_READ)
print mf[0], mf[2**23]
mf.close()
mf.close()

The problem seems to be that mmap_close_method does an
munmap of the data and then sets it to NULL without
checking first whether the data pointer is already
NULL.  The windows part already checks this.  (Please
excuse me if I mess up the protocol for suggesting
patches.)


----------------------------------------------------------------------

>Comment By: Clay Spence (cspence)
Date: 2003-01-10 15:36

Message:
Logged In: YES 
user_id=685289

Sorry, I tried to attach a patch file and it failed to
upload.  It is pretty simple, and looks like:

diff -c -d -T --recursive mmapmodule.c~ mmapmodule.c
*** mmapmodule.c~       Thu Sep  5 18:30:03 2002
--- mmapmodule.c        Fri Jan 10 13:53:28 2003
***************
*** 141,148 ****
        #endif /* MS_WIN32 */
 
        #ifdef UNIX
!               munmap(self->data, self->size);
!               self->data = NULL;
        #endif
 
                Py_INCREF (Py_None);
--- 141,150 ----
        #endif /* MS_WIN32 */
 
        #ifdef UNIX
!               if (self->data != NULL) {
!                       munmap(self->data, self->size);
!                       self->data = NULL;
!               }
        #endif
 
                Py_INCREF (Py_None);


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-10 15:22

Message:
Logged In: YES 
user_id=33168

There's no patch attached.  I think I can guess what it
would look like though. :-)  This code works on linux, but I
was able to provoke the problem on Solaris.

I suspect this problem affects 2.2.2 as well.  Assigning to
me, I'll fix, add a test, and NEWS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665913&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 21:05:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 13:05:40 -0800
Subject: [Patches] [ python-Patches-665913 ] Fix mmap module core dump with unix
Message-ID: <E18X6LU-0007d6-00@sc8-sf-web2.sourceforge.net>

Patches item #665913, was opened at 2003-01-10 14:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665913&group_id=5470

Category: Modules
>Group: Python 2.2.x
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Clay Spence (cspence)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Fix mmap module core dump with unix

Initial Comment:
Calling the close method of an mmap object more than
once would cause a segmentation fault for me (python
2.2.2, compiled with Sun's Forte compilers, though I
doubt that matters, Solaris 2.8 on an ultra-sparc). 
The following code would do it reliably:

"""Demonstrate mmap bug?"""

import os
f=open('junk', 'w')
f.write(2**24 * 'a') # Arbitrary character
f.close()
s = os.stat('junk')    
s.st_size

from mmap import *
f = open('junk')
mf = mmap(f.fileno(), 2**24, access=ACCESS_READ)
print mf[0], mf[2**23]
mf.close()
mf.close()

The problem seems to be that mmap_close_method does an
munmap of the data and then sets it to NULL without
checking first whether the data pointer is already
NULL.  The windows part already checks this.  (Please
excuse me if I mess up the protocol for suggesting
patches.)


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-10 16:05

Message:
Logged In: YES 
user_id=33168

That's what I guessed. :-)  Thanks!

Checked in as:
 Modules/mmapmodule.c 2.42 and 2.35.6.4
 Lib/test/test_mmap.py 1.29 and 1.19.8.6
 Misc/NEWS 1.610 and 1.337.2.4.2.52

----------------------------------------------------------------------

Comment By: Clay Spence (cspence)
Date: 2003-01-10 15:36

Message:
Logged In: YES 
user_id=685289

Sorry, I tried to attach a patch file and it failed to
upload.  It is pretty simple, and looks like:

diff -c -d -T --recursive mmapmodule.c~ mmapmodule.c
*** mmapmodule.c~       Thu Sep  5 18:30:03 2002
--- mmapmodule.c        Fri Jan 10 13:53:28 2003
***************
*** 141,148 ****
        #endif /* MS_WIN32 */
 
        #ifdef UNIX
!               munmap(self->data, self->size);
!               self->data = NULL;
        #endif
 
                Py_INCREF (Py_None);
--- 141,150 ----
        #endif /* MS_WIN32 */
 
        #ifdef UNIX
!               if (self->data != NULL) {
!                       munmap(self->data, self->size);
!                       self->data = NULL;
!               }
        #endif
 
                Py_INCREF (Py_None);


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-10 15:22

Message:
Logged In: YES 
user_id=33168

There's no patch attached.  I think I can guess what it
would look like though. :-)  This code works on linux, but I
was able to provoke the problem on Solaris.

I suspect this problem affects 2.2.2 as well.  Assigning to
me, I'll fix, add a test, and NEWS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665913&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 21:32:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 13:32:52 -0800
Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname
Message-ID: <E18X6lo-00082K-00@sc8-sf-web3.sourceforge.net>

Patches item #664376, was opened at 2003-01-08 07:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.path[0] should contain absolute pathname

Initial Comment:
This patch changes sys.path[0] to contain an absolute 
instead of a relative pathname.

See python-dev thread starting here:
http://mail.python.org/pipermail/python-dev/2003-
January/031896.html

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-10 15:32

Message:
Logged In: YES 
user_id=44345

Here's a somewhat different patch.  I don't know if the actual sysmodule.c
patch is correct or not, but it includes the necessary framework to
verify that realpath() is available.  Pick and choose bits as you like.

Skip

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-10 08:24

Message:
Logged In: YES 
user_id=11105

I believe this problem should be fixed also on systems other
than Windows, or the checkin should be reverted again.

I've prepared a patch based on an idea of Skip Montanaro,
who pointed my to the realpath() function.
It is tested on a SuSE 7.0 Linux system, but I don't know
which #ifdef I have to se around this code. See the patch
for details.

Reopened and unassigned for review.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 09:02

Message:
Logged In: YES 
user_id=11105

Checked in as sysmodule.c, rev 2.112.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 08:00

Message:
Logged In: YES 
user_id=6380

Feel free to check this in.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 07:31

Message:
Logged In: YES 
user_id=11105

The attached patch (sysmodule.diff) fixes the problem on 
Windows - that's the only system where I can test it.

It leaves sys.argv alone and only changes sys.path[0] to an 
absolute pathname.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 21:58:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 13:58:56 -0800
Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname
Message-ID: <E18X7B2-0000Vh-00@sc8-sf-web3.sourceforge.net>

Patches item #664376, was opened at 2003-01-08 08:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.path[0] should contain absolute pathname

Initial Comment:
This patch changes sys.path[0] to contain an absolute 
instead of a relative pathname.

See python-dev thread starting here:
http://mail.python.org/pipermail/python-dev/2003-
January/031896.html

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-10 16:58

Message:
Logged In: YES 
user_id=6380

The abspath.diff patch seems to work.

But the two new includes in sysmodule.c are not needed AFAICT.

Check in time!

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-10 16:32

Message:
Logged In: YES 
user_id=44345

Here's a somewhat different patch.  I don't know if the actual sysmodule.c
patch is correct or not, but it includes the necessary framework to
verify that realpath() is available.  Pick and choose bits as you like.

Skip

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-10 09:24

Message:
Logged In: YES 
user_id=11105

I believe this problem should be fixed also on systems other
than Windows, or the checkin should be reverted again.

I've prepared a patch based on an idea of Skip Montanaro,
who pointed my to the realpath() function.
It is tested on a SuSE 7.0 Linux system, but I don't know
which #ifdef I have to se around this code. See the patch
for details.

Reopened and unassigned for review.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 10:02

Message:
Logged In: YES 
user_id=11105

Checked in as sysmodule.c, rev 2.112.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 09:00

Message:
Logged In: YES 
user_id=6380

Feel free to check this in.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 08:31

Message:
Logged In: YES 
user_id=11105

The attached patch (sysmodule.diff) fixes the problem on 
Windows - that's the only system where I can test it.

It leaves sys.argv alone and only changes sys.path[0] to an 
absolute pathname.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 22:15:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 14:15:08 -0800
Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname
Message-ID: <E18X7Qi-00016X-00@sc8-sf-web3.sourceforge.net>

Patches item #664376, was opened at 2003-01-08 07:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.path[0] should contain absolute pathname

Initial Comment:
This patch changes sys.path[0] to contain an absolute 
instead of a relative pathname.

See python-dev thread starting here:
http://mail.python.org/pipermail/python-dev/2003-
January/031896.html

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-10 16:15

Message:
Logged In: YES 
user_id=44345

Regarding the includes, I was just going by the realpath manpage on 
my Mac and the fact that a quick scan of Include/*.h didn't turn them up.
S

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-10 15:58

Message:
Logged In: YES 
user_id=6380

The abspath.diff patch seems to work.

But the two new includes in sysmodule.c are not needed AFAICT.

Check in time!

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-10 15:32

Message:
Logged In: YES 
user_id=44345

Here's a somewhat different patch.  I don't know if the actual sysmodule.c
patch is correct or not, but it includes the necessary framework to
verify that realpath() is available.  Pick and choose bits as you like.

Skip

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-10 08:24

Message:
Logged In: YES 
user_id=11105

I believe this problem should be fixed also on systems other
than Windows, or the checkin should be reverted again.

I've prepared a patch based on an idea of Skip Montanaro,
who pointed my to the realpath() function.
It is tested on a SuSE 7.0 Linux system, but I don't know
which #ifdef I have to se around this code. See the patch
for details.

Reopened and unassigned for review.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 09:02

Message:
Logged In: YES 
user_id=11105

Checked in as sysmodule.c, rev 2.112.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 08:00

Message:
Logged In: YES 
user_id=6380

Feel free to check this in.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 07:31

Message:
Logged In: YES 
user_id=11105

The attached patch (sysmodule.diff) fixes the problem on 
Windows - that's the only system where I can test it.

It leaves sys.argv alone and only changes sys.path[0] to an 
absolute pathname.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 22:18:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 14:18:53 -0800
Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname
Message-ID: <E18X7UL-0001Pl-00@sc8-sf-web4.sourceforge.net>

Patches item #664376, was opened at 2003-01-08 08:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.path[0] should contain absolute pathname

Initial Comment:
This patch changes sys.path[0] to contain an absolute 
instead of a relative pathname.

See python-dev thread starting here:
http://mail.python.org/pipermail/python-dev/2003-
January/031896.html

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-10 17:18

Message:
Logged In: YES 
user_id=6380

stdlib.h is included by Python.h and pyport.h.

I don't see anything in sys/param.h that provides realpath().

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-10 17:15

Message:
Logged In: YES 
user_id=44345

Regarding the includes, I was just going by the realpath manpage on 
my Mac and the fact that a quick scan of Include/*.h didn't turn them up.
S

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-10 16:58

Message:
Logged In: YES 
user_id=6380

The abspath.diff patch seems to work.

But the two new includes in sysmodule.c are not needed AFAICT.

Check in time!

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-10 16:32

Message:
Logged In: YES 
user_id=44345

Here's a somewhat different patch.  I don't know if the actual sysmodule.c
patch is correct or not, but it includes the necessary framework to
verify that realpath() is available.  Pick and choose bits as you like.

Skip

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-10 09:24

Message:
Logged In: YES 
user_id=11105

I believe this problem should be fixed also on systems other
than Windows, or the checkin should be reverted again.

I've prepared a patch based on an idea of Skip Montanaro,
who pointed my to the realpath() function.
It is tested on a SuSE 7.0 Linux system, but I don't know
which #ifdef I have to se around this code. See the patch
for details.

Reopened and unassigned for review.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 10:02

Message:
Logged In: YES 
user_id=11105

Checked in as sysmodule.c, rev 2.112.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 09:00

Message:
Logged In: YES 
user_id=6380

Feel free to check this in.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 08:31

Message:
Logged In: YES 
user_id=11105

The attached patch (sysmodule.diff) fixes the problem on 
Windows - that's the only system where I can test it.

It leaves sys.argv alone and only changes sys.path[0] to an 
absolute pathname.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 23:08:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 15:08:21 -0800
Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname
Message-ID: <E18X8GD-0003Ra-00@sc8-sf-web4.sourceforge.net>

Patches item #664376, was opened at 2003-01-08 07:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.path[0] should contain absolute pathname

Initial Comment:
This patch changes sys.path[0] to contain an absolute 
instead of a relative pathname.

See python-dev thread starting here:
http://mail.python.org/pipermail/python-dev/2003-
January/031896.html

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-10 17:08

Message:
Logged In: YES 
user_id=44345

On my Mac stdlib.h contains the declaration for realpath() and sys/param.h defines MAXPATHLEN which is referenced in the realpath man page.  On
my Mandrake system, realpath() is declared in stdlib.h.  The man page there
references limits.h, though I didn't see any constant like MAXPATHLEN
referenced in the man page.

I guess dump the #includes and wait to see if any platforms complain.
S


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-10 16:18

Message:
Logged In: YES 
user_id=6380

stdlib.h is included by Python.h and pyport.h.

I don't see anything in sys/param.h that provides realpath().

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-10 16:15

Message:
Logged In: YES 
user_id=44345

Regarding the includes, I was just going by the realpath manpage on 
my Mac and the fact that a quick scan of Include/*.h didn't turn them up.
S

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-10 15:58

Message:
Logged In: YES 
user_id=6380

The abspath.diff patch seems to work.

But the two new includes in sysmodule.c are not needed AFAICT.

Check in time!

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-10 15:32

Message:
Logged In: YES 
user_id=44345

Here's a somewhat different patch.  I don't know if the actual sysmodule.c
patch is correct or not, but it includes the necessary framework to
verify that realpath() is available.  Pick and choose bits as you like.

Skip

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-10 08:24

Message:
Logged In: YES 
user_id=11105

I believe this problem should be fixed also on systems other
than Windows, or the checkin should be reverted again.

I've prepared a patch based on an idea of Skip Montanaro,
who pointed my to the realpath() function.
It is tested on a SuSE 7.0 Linux system, but I don't know
which #ifdef I have to se around this code. See the patch
for details.

Reopened and unassigned for review.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 09:02

Message:
Logged In: YES 
user_id=11105

Checked in as sysmodule.c, rev 2.112.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 08:00

Message:
Logged In: YES 
user_id=6380

Feel free to check this in.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 07:31

Message:
Logged In: YES 
user_id=11105

The attached patch (sysmodule.diff) fixes the problem on 
Windows - that's the only system where I can test it.

It leaves sys.argv alone and only changes sys.path[0] to an 
absolute pathname.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470


From noreply@sourceforge.net  Fri Jan 10 23:56:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 15:56:48 -0800
Subject: [Patches] [ python-Patches-661368 ] Add sysexits.h EX_* symbols to posix
Message-ID: <E18X916-0003YX-00@sc8-sf-web1.sourceforge.net>

Patches item #661368, was opened at 2003-01-02 18:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661368&group_id=5470

Category: Modules
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Add sysexits.h EX_* symbols to posix

Initial Comment:
The following patch adds the EX_* symbols to the posix
module (exposed through os of course).  These are
defined in sysexits.h.  Done this way since the list
can be (slightly) different depending on the OS.  This
patch includes configure updates to detect sysexits.h.

I'll update docs if it's approved for Py2.3.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-10 18:56

Message:
Logged In: YES 
user_id=33168

Barry checked this in as Modules/posixmodule.c 2.281, so I'm
closing.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-06 17:55

Message:
Logged In: YES 
user_id=12800

Except they aren't alphabetical now. ;)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 03:10

Message:
Logged In: YES 
user_id=21627

I'm not concerned about the order of symbols in posixmodule,
but about the order of header names in configure.in - those
should be alphabetical.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-02 21:58

Message:
Logged In: YES 
user_id=12800

The order is roughly the order found in Linux's sysexits.h,
which is in numerical order (there is one extra symbol found
in Solaris's sysexit.h that isn't in Linux's).

I'll work out doc updates before I commit.  Thanks for
looking at it.  The configure goo was because I didn't trim
my "cvs diff -u" output. ;)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-02 19:03

Message:
Logged In: YES 
user_id=21627

Never heard about sysexit.h... The patch looks fine, except
that the list of headers to test should be roughly in
alphabetical order (so that it is easier to spot
duplicates). Please apply it.

In general, there is no need to attach the generated
configure to SF bug reports, it will outdate quickly.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-01-02 18:46

Message:
Logged In: YES 
user_id=12800

I know all about this PITA, thought I had, guess I didn't. ;(

Trying again...

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-02 18:15

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661368&group_id=5470


From noreply@sourceforge.net  Sat Jan 11 01:15:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 17:15:27 -0800
Subject: [Patches] [ python-Patches-515003 ] Added HTTP{,S}ProxyConnection
Message-ID: <E18XAFD-0006Eb-00@sc8-sf-web4.sourceforge.net>

Patches item #515003, was opened at 2002-02-08 16:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Mihai Ibanescu (misa)
Assigned to: Jeremy Hylton (jhylton)
Summary: Added HTTP{,S}ProxyConnection

Initial Comment:
This patch adds HTTP*Connection classes for proxy
connections. Authenticated proxies are also supported.

One can argue urllib2 already implements this. It does
not do HTTPS tunneling through proxies, and this is
intended to be lower-level than urllib2.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-10 20:15

Message:
Logged In: YES 
user_id=33168

Uploading patch from Isaac Salsberg.  I removed some more
comments.  Jeremy (or Martin) can you review this.  If it's
read, I can check it in.

There still needs to be a doc and tests.  I'll check if
either of the old patches has any.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-01 14:52

Message:
Logged In: YES 
user_id=33168

Isaac, can you send me the patch?  nnorwitz@users.sf.net
should work

----------------------------------------------------------------------

Comment By: Isaac Salsberg (isalsberg)
Date: 2002-12-19 20:54

Message:
Logged In: YES 
user_id=663978

Neal, taht's right, I can not attach a file. 
I don't think is a good idea to close this patch, because
Misa is still working on it to fix some  persistence issue.

The version I created is based on the current Misa's 
version, so it has the same persistence problem. It just
was adapted to be used with Python 2.2.2. So we need to
wait for Misa's final version. 

I sent the patch to Misa, in case he wants to atach it here 
meanwhile the last version arrives. Except for persistence, 
It is working for me in a production environment. 

Anyway, If You need the patch I can send it. Just give me 
an email address. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-14 21:09

Message:
Logged In: YES 
user_id=33168

Isaac, I don't believe SF allows you to attach a file to
someone else's patch.  Please submit a new patch.  In the
comments for the new patch refer to this patch and indicate
if it supercedes this patch (ie, should this patch be
closed).  Also, it would be nice if you can add a comment to
this patch mentioning the new patch number.  Thanks!

----------------------------------------------------------------------

Comment By: Isaac Salsberg (isalsberg)
Date: 2002-12-14 19:52

Message:
Logged In: YES 
user_id=663978

To make this patch work with the "buggy"  IIS using python 
2.2 or 2.2.1 with https, You need to install also these 2 
patches:

551273 (fix httplib bug with 100 Continue) and
500311 (work around for buggy https servers)

Python 2.2.2 by the other hand, has already incorparated 
those two patches, so You only need to add the HTTP{S} 
(515003) proxy patch. But since httplib has changed,  Misa's 
diff file will fail.

I have created a diff file that works with python 2.2.2, which 
also includes a new example that works using a certificate  
file in PEM format. I wanted to attach the file, however
I could not find out how :-(

----------------------------------------------------------------------

Comment By: Mihai Ibanescu (misa)
Date: 2002-11-05 15:56

Message:
Logged In: YES 
user_id=205865

I am having problems with proxying and keepalive
connections. Setting to a lower priority until I figure out
the documentation.

----------------------------------------------------------------------

Comment By: Mihai Ibanescu (misa)
Date: 2002-10-07 17:20

Message:
Logged In: YES 
user_id=205865

Boy, two months. Yes, I'll go back to working on the patch.
Sorry for the delay.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-07 17:17

Message:
Logged In: YES 
user_id=21627

misa, is a patch forthcoming?

----------------------------------------------------------------------

Comment By: Mihai Ibanescu (misa)
Date: 2002-07-15 17:37

Message:
Logged In: YES 
user_id=205865

- I agree about the comments. I'll make them reasonable.
- one underscore is fine
- I intended to have a patch that works with python 1.5, but
then again the module itself doesn't run with 1.5 anyway, so
good point.
- When you make a connection to a server through a proxy,
you have to connect to the proxy, but everything else should
be the same, i.e. the Host: field has to refer to the server
and so on. I wanted to reuse the code from _set_hostport,
which saves the host and port in self.host, self.port. Had
to do it twice, once for the proxy hostname, once for the
server's. _set_hostport takes care of the default port and
of the "hostname:port" syntax, which is convenient.

I'll put together a patched patch and upload it.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-07-15 17:21

Message:
Logged In: YES 
user_id=31392

The proposed classes seem useful enough, but I would like to
make several suggestions for the implementation.

- There are too many comments.  Comments should only be
added when 
   the intent of the code needs to be explained.  We
definitely don't need
   one comment for each line of code.  The comment in the
HTTPS proxy
   putrequest() is an example of a helpful comment.

- Just use a single underscore for private variables.

- Please use string methods instead of the string module.

- I don't understand the logic of switching the host/port
back and forth.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-07-15 16:52

Message:
Logged In: YES 
user_id=31392

I'll take a look.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-07-12 11:46

Message:
Logged In: YES 
user_id=6380

Assigning to Jeremy in the hope that he can provide a review.

----------------------------------------------------------------------

Comment By: Mihai Ibanescu (misa)
Date: 2002-06-23 23:03

Message:
Logged In: YES 
user_id=205865

The newer patch is generated against the latest CVS tree,
and it provides additional documentation.

----------------------------------------------------------------------

Comment By: Mihai Ibanescu (misa)
Date: 2002-06-11 14:47

Message:
Logged In: YES 
user_id=205865

Sorry, been caught with a zillion of other things to do.
I'll try to reorganize it somehow and ask for opinions.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-06-11 14:42

Message:
Logged In: YES 
user_id=31392

misa-- any progress on this patch?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 18:12

Message:
Logged In: YES 
user_id=6380

OK, thanks; I'll wait!

----------------------------------------------------------------------

Comment By: Mihai Ibanescu (misa)
Date: 2002-03-01 17:58

Message:
Logged In: YES 
user_id=205865

I will add documentation and show the intended usage.
urllib* doesn't deal with proxying over SSL (using CONNECT
instead of GET/POST). urllib* also use the compatibility
classes, HTTP/HTTPS, instead of HTTPConnection (this is not
an argument by itself).
Thanks for the suggestion.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:40

Message:
Logged In: YES 
user_id=6380

This patch fails to seduce me. There's no explanation why
this would be useful, or how it should be used, and no
documentation, and a hint that urllib2 already does this.

Maybe you can get someone who's known on python-dev to
champion it, if you think it's useful?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470


From noreply@sourceforge.net  Sat Jan 11 03:49:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 19:49:31 -0800
Subject: [Patches] [ python-Patches-658327 ] Add inet_pton and inet_ntop to socket
Message-ID: <E18XCeJ-0001bA-00@sc8-sf-web4.sourceforge.net>

Patches item #658327, was opened at 2002-12-24 16:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Add inet_pton and inet_ntop to socket

Initial Comment:
Patch is against current CVS and adds two socket module
functions, inet_pton and inet_ntop.  Both of these
should be available on all platforms (because of other
dependancies in the code) so I don't think portability
is a problem.  inet_ntop converts a packed IP address
to a human-readable '.' or ':' separated string
representation of the IP.  inet_pton performs the
reverse operation.

(Potential) problems: inet_pton sets errno to ENOSPC,
which may lead to a confusing error message.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-10 22:49

Message:
Logged In: YES 
user_id=33168

JP, do you agree with my comment on 2002-12-30 about the
checks?  I have attached an updated patch.  Please review
and verify this is correct.

Thank you for the additional tests.  Feel free to submit
patches with additional tests for any and all modules!

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2002-12-31 11:52

Message:
Logged In: YES 
user_id=366566

Doc, NEWS, and test_socket patch attached.  I didn't notice
any inet_aton/inet_ntoa tests in the module so I added a
couple for those as well (I excluded a test for
inet_ntoa('255.255.255.255') ;) Also included are a couple
IPv6 tests.  I'm not sure if these are appropriate, since
many systems may still lack the required support for them to
pass.  I'll leave it up to you to decide whether they should
be commented out or removed or whatever.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 08:17

Message:
Logged In: YES 
user_id=21627

I agree that such a change should be added. Neal, you have
given this patch more attention than I did - please check it
in when you consider it complete. I just like to point out
that it is missing documentation changes (libsocket.tex), a
NEWS entry, and a test case. kuran, please provide those as
a single patch file.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-30 19:11

Message:
Logged In: YES 
user_id=33168

ISTM that in socket_inet_ntop() you need to verify the size
of the packed value passed in.  If the user passes an empty
string, inet_ntop() could read beyond the buffer passed in,
potentially causing a core dump.

The checks could be something like this:

  if (af == AF_INET && len != sizeof(struct in_addr))
  else if (af == AF_INET6 && len != sizeof(struct in6_addr))

Do this make sense?

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2002-12-27 10:39

Message:
Logged In: YES 
user_id=366566

The use case I have for it at the moment is a DNS server
(Twisted.names).  inet_pton allows me to handle IPv6
addresses, so it allows me to support AAAA and A6 records. 
I believe an IPv6 capable socks proxy would find this useful
as well.  Basically, low level network stuff.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-27 05:23

Message:
Logged In: YES 
user_id=21627

What is the rationale for providing this functionality?

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2002-12-26 13:32

Message:
Logged In: YES 
user_id=366566

Ooops, I made two, and uploaded the wrong one >:O  Sorry. 
Dunno if it's still helpful, but here's the unified diff.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-26 13:10

Message:
Logged In: YES 
user_id=33168

Next time, please use context or unified diff.  -c or -u
option to cvs diff:  cvs diff -c ...

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2002-12-24 16:05

Message:
Logged In: YES 
user_id=366566

Sourceforge decided not to attach the file the first time...
 Here it is.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470


From noreply@sourceforge.net  Sat Jan 11 04:07:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 10 Jan 2003 20:07:33 -0800
Subject: [Patches] [ python-Patches-664376 ] sys.path[0] should contain absolute pathname
Message-ID: <E18XCvl-0001uW-00@sc8-sf-web2.sourceforge.net>

Patches item #664376, was opened at 2003-01-08 08:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.path[0] should contain absolute pathname

Initial Comment:
This patch changes sys.path[0] to contain an absolute 
instead of a relative pathname.

See python-dev thread starting here:
http://mail.python.org/pipermail/python-dev/2003-
January/031896.html

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-10 23:07

Message:
Logged In: YES 
user_id=6380

Yeah, but stdlib.h is *already* being included (by Python.h)
and MAXPATHLEN is also already available (through osdefs.h).

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-10 18:08

Message:
Logged In: YES 
user_id=44345

On my Mac stdlib.h contains the declaration for realpath() and sys/param.h defines MAXPATHLEN which is referenced in the realpath man page.  On
my Mandrake system, realpath() is declared in stdlib.h.  The man page there
references limits.h, though I didn't see any constant like MAXPATHLEN
referenced in the man page.

I guess dump the #includes and wait to see if any platforms complain.
S


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-10 17:18

Message:
Logged In: YES 
user_id=6380

stdlib.h is included by Python.h and pyport.h.

I don't see anything in sys/param.h that provides realpath().

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-10 17:15

Message:
Logged In: YES 
user_id=44345

Regarding the includes, I was just going by the realpath manpage on 
my Mac and the fact that a quick scan of Include/*.h didn't turn them up.
S

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-10 16:58

Message:
Logged In: YES 
user_id=6380

The abspath.diff patch seems to work.

But the two new includes in sysmodule.c are not needed AFAICT.

Check in time!

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-10 16:32

Message:
Logged In: YES 
user_id=44345

Here's a somewhat different patch.  I don't know if the actual sysmodule.c
patch is correct or not, but it includes the necessary framework to
verify that realpath() is available.  Pick and choose bits as you like.

Skip

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-10 09:24

Message:
Logged In: YES 
user_id=11105

I believe this problem should be fixed also on systems other
than Windows, or the checkin should be reverted again.

I've prepared a patch based on an idea of Skip Montanaro,
who pointed my to the realpath() function.
It is tested on a SuSE 7.0 Linux system, but I don't know
which #ifdef I have to se around this code. See the patch
for details.

Reopened and unassigned for review.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 10:02

Message:
Logged In: YES 
user_id=11105

Checked in as sysmodule.c, rev 2.112.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 09:00

Message:
Logged In: YES 
user_id=6380

Feel free to check this in.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-08 08:31

Message:
Logged In: YES 
user_id=11105

The attached patch (sysmodule.diff) fixes the problem on 
Windows - that's the only system where I can test it.

It leaves sys.argv alone and only changes sys.path[0] to an 
absolute pathname.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664376&group_id=5470


From noreply@sourceforge.net  Sat Jan 11 11:56:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 11 Jan 2003 03:56:55 -0800
Subject: [Patches] [ python-Patches-663983 ] PyList_NewNoZero
Message-ID: <E18XKFz-0005Kf-00@sc8-sf-web2.sourceforge.net>

Patches item #663983, was opened at 2003-01-07 15:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663983&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyList_NewNoZero

Initial Comment:
PyList_New(n) spends time initializing every space to 
zero.  In many (but not all cases), the caller 
immediately refills in every space and has no error 
exits prior to filling the space.  In those cases, time 
would be saved by using a version of PyList_New(n) 
that did not do the initialization.

The same holds true for tuples.

Creating new lists and tuples is one of the most 
common operations in python and may warrant this 
micro-optimization.

The attached patch is a proof-of-concept.

The only downside is that it shares the same risks as 
it SET_ITEM macro cousins -- the user of the function 
has the burden of making sure that certain conditions 
hold (in the case, promising to fill out every entry with 
a valid python object or NULL).

Guido, what do you think?  If it gets a plus one, I can 
make a more thorough patch and get a detailed 
review.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-07 15:51

Message:
Logged In: YES 
user_id=6380

I'm not comfortable with this, I find it hard to believe
that a memset() can make much difference given everything
else that goes on (like INCREF'ing every single thing that
gets stored in a list even by PyList_SET_ITEM), I see no
performance data backing up the change, and I would like to
keep the annual growth of Python within bounds. So, -1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663983&group_id=5470


From noreply@sourceforge.net  Sat Jan 11 11:56:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 11 Jan 2003 03:56:55 -0800
Subject: [Patches] [ python-Patches-663983 ] PyList_NewNoZero
Message-ID: <E18XKFz-0005Kj-00@sc8-sf-web2.sourceforge.net>

Patches item #663983, was opened at 2003-01-07 15:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663983&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyList_NewNoZero

Initial Comment:
PyList_New(n) spends time initializing every space to 
zero.  In many (but not all cases), the caller 
immediately refills in every space and has no error 
exits prior to filling the space.  In those cases, time 
would be saved by using a version of PyList_New(n) 
that did not do the initialization.

The same holds true for tuples.

Creating new lists and tuples is one of the most 
common operations in python and may warrant this 
micro-optimization.

The attached patch is a proof-of-concept.

The only downside is that it shares the same risks as 
it SET_ITEM macro cousins -- the user of the function 
has the burden of making sure that certain conditions 
hold (in the case, promising to fill out every entry with 
a valid python object or NULL).

Guido, what do you think?  If it gets a plus one, I can 
make a more thorough patch and get a detailed 
review.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-07 15:51

Message:
Logged In: YES 
user_id=6380

I'm not comfortable with this, I find it hard to believe
that a memset() can make much difference given everything
else that goes on (like INCREF'ing every single thing that
gets stored in a list even by PyList_SET_ITEM), I see no
performance data backing up the change, and I would like to
keep the annual growth of Python within bounds. So, -1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=663983&group_id=5470


From noreply@sourceforge.net  Sat Jan 11 17:04:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 11 Jan 2003 09:04:26 -0800
Subject: [Patches] [ python-Patches-658327 ] Add inet_pton and inet_ntop to socket
Message-ID: <E18XP3a-000685-00@sc8-sf-web4.sourceforge.net>

Patches item #658327, was opened at 2002-12-24 16:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Add inet_pton and inet_ntop to socket

Initial Comment:
Patch is against current CVS and adds two socket module
functions, inet_pton and inet_ntop.  Both of these
should be available on all platforms (because of other
dependancies in the code) so I don't think portability
is a problem.  inet_ntop converts a packed IP address
to a human-readable '.' or ':' separated string
representation of the IP.  inet_pton performs the
reverse operation.

(Potential) problems: inet_pton sets errno to ENOSPC,
which may lead to a confusing error message.


----------------------------------------------------------------------

>Comment By: Jp Calderone (kuran)
Date: 2003-01-11 12:04

Message:
Logged In: YES 
user_id=366566

Yea, testing for the proper input length is definitely
something that should be done.  The patch looks good, but
for one thing.  If the specified address family is neither
AF_INET nor AF_INET6, the length won't be tested and the
underlying inet_ntop will be called.  This isn't a problem
now (afaik) because only those two address families are
support, but in a future libc version with more supported
address families, it might open a similar hole to the one
you've fixed.  Perhaps the

+       } else {
+               PyErr_SetString(socket_error, "unknown
address family");
+               return NULL;
+       }

should be moved up from the second if-grouping to follow the
first if-grouping.  Everything else looks good to me. 
Thanks for taking the time to look at this :)



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-10 22:49

Message:
Logged In: YES 
user_id=33168

JP, do you agree with my comment on 2002-12-30 about the
checks?  I have attached an updated patch.  Please review
and verify this is correct.

Thank you for the additional tests.  Feel free to submit
patches with additional tests for any and all modules!

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2002-12-31 11:52

Message:
Logged In: YES 
user_id=366566

Doc, NEWS, and test_socket patch attached.  I didn't notice
any inet_aton/inet_ntoa tests in the module so I added a
couple for those as well (I excluded a test for
inet_ntoa('255.255.255.255') ;) Also included are a couple
IPv6 tests.  I'm not sure if these are appropriate, since
many systems may still lack the required support for them to
pass.  I'll leave it up to you to decide whether they should
be commented out or removed or whatever.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-31 08:17

Message:
Logged In: YES 
user_id=21627

I agree that such a change should be added. Neal, you have
given this patch more attention than I did - please check it
in when you consider it complete. I just like to point out
that it is missing documentation changes (libsocket.tex), a
NEWS entry, and a test case. kuran, please provide those as
a single patch file.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-30 19:11

Message:
Logged In: YES 
user_id=33168

ISTM that in socket_inet_ntop() you need to verify the size
of the packed value passed in.  If the user passes an empty
string, inet_ntop() could read beyond the buffer passed in,
potentially causing a core dump.

The checks could be something like this:

  if (af == AF_INET && len != sizeof(struct in_addr))
  else if (af == AF_INET6 && len != sizeof(struct in6_addr))

Do this make sense?

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2002-12-27 10:39

Message:
Logged In: YES 
user_id=366566

The use case I have for it at the moment is a DNS server
(Twisted.names).  inet_pton allows me to handle IPv6
addresses, so it allows me to support AAAA and A6 records. 
I believe an IPv6 capable socks proxy would find this useful
as well.  Basically, low level network stuff.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-12-27 05:23

Message:
Logged In: YES 
user_id=21627

What is the rationale for providing this functionality?

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2002-12-26 13:32

Message:
Logged In: YES 
user_id=366566

Ooops, I made two, and uploaded the wrong one >:O  Sorry. 
Dunno if it's still helpful, but here's the unified diff.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-26 13:10

Message:
Logged In: YES 
user_id=33168

Next time, please use context or unified diff.  -c or -u
option to cvs diff:  cvs diff -c ...

----------------------------------------------------------------------

Comment By: Jp Calderone (kuran)
Date: 2002-12-24 16:05

Message:
Logged In: YES 
user_id=366566

Sourceforge decided not to attach the file the first time...
 Here it is.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658327&group_id=5470


From noreply@sourceforge.net  Sun Jan 12 03:46:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 11 Jan 2003 19:46:21 -0800
Subject: [Patches] [ python-Patches-666484 ] Japanese Unicode Codecs
Message-ID: <E18XZ4n-0000UX-00@sc8-sf-web2.sourceforge.net>

Patches item #666484, was opened at 2003-01-12 12:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=666484&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: SUZUKI Hisao (suzuki_hisao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Japanese Unicode Codecs

Initial Comment:
This is an implementation of a set of Japanese Unicode
codecs
for Python 2.2 and 2.3.  Three major encodings are
supported:
EUC-JP, Shift_JIS and ISO-2022-JP.

It is in pure Python, of a reasonable size (< 80KB),
and with
an effective means to modify the mapping tables.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=666484&group_id=5470


From noreply@sourceforge.net  Sun Jan 12 12:33:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 12 Jan 2003 04:33:47 -0800
Subject: [Patches] [ python-Patches-666484 ] Japanese Unicode Codecs
Message-ID: <E18XhJD-0006Gw-00@sc8-sf-web2.sourceforge.net>

Patches item #666484, was opened at 2003-01-12 04:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=666484&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 3
Submitted By: SUZUKI Hisao (suzuki_hisao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Japanese Unicode Codecs

Initial Comment:
This is an implementation of a set of Japanese Unicode
codecs
for Python 2.2 and 2.3.  Three major encodings are
supported:
EUC-JP, Shift_JIS and ISO-2022-JP.

It is in pure Python, of a reasonable size (< 80KB),
and with
an effective means to modify the mapping tables.


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-12 13:33

Message:
Logged In: YES 
user_id=38388

Are you aware of the codecs written by Tamito KAJIYAMA ?

   http://www.asahi-net.or.jp/~rd6t-kjym/python/

These are written in C and provide a much improved performance
over Python based ones. They cover the same set of encodings you
have in your packagea dn also include a complete test suite
for the
codecs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=666484&group_id=5470


From noreply@sourceforge.net  Sun Jan 12 20:27:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 12 Jan 2003 12:27:04 -0800
Subject: [Patches] [ python-Patches-473586 ] SimpleXMLRPCServer - fixes and CGI
Message-ID: <E18XohE-0001To-00@sc8-sf-web1.sourceforge.net>

Patches item #473586, was opened at 2001-10-22 09:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
Assigned to: Fredrik Lundh (effbot)
Summary: SimpleXMLRPCServer - fixes and CGI

Initial Comment:
Changes:

o treats xmlrpclib.Fault's correctly (no longer 
absorbes them as generic exceptions)
o changed failed marshal to generate a useful Fault 
instead of an internal server error
o adds a new class to make writing XML-RPC functions 
embedded in other servers, using CGI, easier (tested 
with APACHE)
o to support the above, added a new dispatch helper 
class SimpleXMLRPCDispatcher


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-12 21:27

Message:
Logged In: YES 
user_id=21627

Fredrik, do you see any reason to reject this patch, or
request further modifications?

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2002-12-30 07:57

Message:
Logged In: YES 
user_id=108973

Attachment's aren't working right now, here is the 
documentation inline (sorry, I don't know enough about LaTeX 
to do my own markup):

First page
----------

The SimpleXMLRPCServer module provides a basic 
framework for XML-RPC servers written in Python. Servers 
can either be free standing, using SimpleXMLRPCServer, or 
embedded in a CGI environment, using 
CGIXMLRPCRequestHandler.


class SimpleXMLRPCServer(addr[, requestHandler[, 
logRequests]]) 
Create a new server instance based on 
SocketServer.TCPServer. The requestHandler parameter 
should be a factory for request handler instances; it defaults 
to SimpleXMLRPCRequestHandler. The addr and 
requestHandler parameters are passed to the 
SocketServer.TCPServer constructor. If logRequests is true 
(the default), requests will be logged; setting this parameter 
to false will turn off logging. This class provides methods for 
registration of functions that can be called by the XML-RPC 
protocol. 


class CGIXMLRPCRequestHandler()
Create a new instance to handle XML-RPC requests in a CGI 
environment.

SimpleXMLRPCServer
------------------

The SimpleXMLRPCServer class is based on 
SocketServer.TCPServer and provides a means of creating 
simple, stand alone XML-RPC servers.

register_function(function[, name]) 
Register a function that can respond to XML-RPC requests. If 
name is given, it will be the method name associated with 
function, otherwise function.__name__ will be used. name 
can be either a normal or Unicode string, and may contain 
characters not legal in Python identifiers, including the period 
character. 

register_instance(instance) 
Register an object which is used to expose method names 
which have not been registered using register_function(). If 
instance contains a _dispatch() method, it is called with the 
requested method name and the parameters from the 
request; the return value is returned to the client as the result. 
If instance does not have a _dispatch() method, it is searched 
for an attribute matching the name of the requested method; if 
the requested method name contains periods, each 
component of the method name is searched for individually, 
with the effect that a simple hierarchical search is performed. 
The value found from this search is then called with the 
parameters from the request, and the return value is passed 
back to the client. 

register_introspection_functions
Registers the XML-RPC introspection functions 
system.listMethods, system.methodHelp and 
system.methodSignature.

register_multicall_functions
Registers the XML-RPC multicall function system.multicall.

Example:

class MyFuncs:
    def div(self, x, y) : return div(x,y)


server = SimpleXMLRPCServer(("localhost", 8000))
server.register_function(pow)
server.register_function(lambda x,y: x+y, 'add')
server.register_introspection_functions()
server.register_instance(MyFuncs())
server.serve_forever()

CGIXMLRPCRequestHandler
-----------------------

The CGIXMLRPCRequestHandler class can be used to 
handle XML-RPC requests sent to Python CGI scripts.


register_function(function[, name]) 
Register a function that can respond to XML-RPC requests. If 
name is given, it will be the method name associated with 
function, otherwise function.__name__ will be used. name 
can be either a normal or Unicode string, and may contain 
characters not legal in Python identifiers, including the period 
character. 

register_instance(instance) 
Register an object which is used to expose method names 
which have not been registered using register_function(). If 
instance contains a _dispatch() method, it is called with the 
requested method name and the parameters from the 
request; the return value is returned to the client as the result. 
If instance does not have a _dispatch() method, it is searched 
for an attribute matching the name of the requested method; if 
the requested method name contains periods, each 
component of the method name is searched for individually, 
with the effect that a simple hierarchical search is performed. 
The value found from this search is then called with the 
parameters from the request, and the return value is passed 
back to the client. 

register_introspection_functions
Registers the XML-RPC introspection functions 
system.listMethods, system.methodHelp and 
system.methodSignature.

register_multicall_functions
Registers the XML-RPC multicall function system.multicall.

handle_request(self, request_text = None)
Handles a XML-RPC request. If request_text is given, it 
should be the POST data provided by the HTTP server, 
otherwise the contents of stdin will be used.

Example:

class MyFuncs:
    def div(self, x, y) : return div(x,y)


handler = CGIXMLRPCRequestHandler(("localhost", 8000))
handler.register_function(pow)
handler.register_function(lambda x,y: x+y, 'add')
handler.register_introspection_functions()
handler.register_instance(MyFuncs())
handler.handle_request()


----------------------------------------------------------------------

Comment By: Robin Becker (rgbecker)
Date: 2002-11-04 14:19

Message:
Logged In: YES 
user_id=6946

Thanks I have applied the v5 patch and it seems fine,
I suppose it is probably better to use the patch rather
than stick with Brian's old code as I guess it will
gradually get more and more out of date.

Perhaps all the old introspection stuff belongs in a cookbook
entry?

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2002-11-01 00:46

Message:
Logged In: YES 
user_id=108973

Martin, I don't have a lot of bandwidth right now but I'll try to 
do that soon.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-26 17:23

Message:
Logged In: YES 
user_id=21627

Brian, the patch looks good to me. However, can you please
also supply patches to Doc/lib/libsimplexmlrpc?

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2002-03-18 20:41

Message:
Logged In: YES 
user_id=108973

OK, I fixed the backwards compatibility problem.

Also added:
o support for the XML-RPC introspection methods 
system.listMethods and system.methodHelp
o support for the XML-RPC boxcaring method system.multicall

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-12-04 20:51

Message:
Logged In: YES 
user_id=108973

Please do not accept this patch past 2.2 release; there are 
so non-backwards compatible changes that need to be though 
through.

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-10-23 20:02

Message:
Logged In: YES 
user_id=108973

- a few extra comments
- moved a xmlrpclib.loads() inside an exception handler so 
an XML-RPC fault is generated for malformed requests


----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-10-22 20:59

Message:
Logged In: YES 
user_id=108973

The advantage of the entire patch being accepted before 2.2 
is that there is an API change and, once 2.2 is release, we 
will probably have to make a bit of an attempt to maintain 
backwards compatibility.

If this patch is too high-risk for 2.2 then I can certainly 
design a bug-fix patch for 2.2 and submit a new patch for 
2.3 (that is API compatible with 2.2).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-10-22 20:43

Message:
Logged In: YES 
user_id=21627

Brian, please note that Python 2.2b1 has been released, so 
no new features are acceptable until 2.2. So unless 
Fredrik Lundh wants to accept your entire patch, I think 
it has little chance to get integrated for the next few 
months.
If you want pieces of it accepted, I'd recommend to split 
it into bug fixes and new features; bug fixes are still 
acceptable.


----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-10-22 20:27

Message:
Logged In: YES 
user_id=108973

I just can't stop mucking with it. This time there are only 
documentation changes. I should also have pointed out that 
this patch changes the mechanism for overriding the 
dispatch mechanism: you used to subclass the request 
handler, now you subclass the server. I believe that this 
change is correct because the server actually has the 
required state information to do the dispatching.

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-10-22 09:35

Message:
Logged In: YES 
user_id=108973

Changed a name to fit other naming conventions

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470


From hanlu@msn.com  Tue Jan 14 07:08:15 2003
From: hanlu@msn.com (hanlu@msn.com)
Date: Tue, 14 Jan 2003 03:08:15 -0400
Subject: [Patches] Make IT big... FOREVER
Message-ID: <000100d6cb21$bbc58554$75155010@xrwkwcc.lwg>

<html><body><div align="Center"><table cellpadding="2" cellspacing="2" border="0" width="80%"><tbody><tr><td valign="Top"><div align="Center"><div align="Center"><div align="Center"><div align="Center"><b><font color="blue"><font size="+3"><i>"Want a <font color="#ff0000">BIG </font>Penis?"</i></font></b><br>   </div><div align="Center"><font size="+1" color="blue">
Experience the results you've always wanted</font><font color="blue" size="+1"><br></font><font size="+1" color="blue">with a MASSIVE scientific breakthrough:</font></div></div></div><h2><font color="blue"><font color="#ff0000" size="3">Our Doctor-Approved Pill Will Actually Expand, Lengthen<br> And Enlarge Your Penis. <u>100% GUARANTEED!</u></font></font></h2><font color="blue"><i><b><font face="Verdana, Arial, Helvetica, sans-serif" color="#ff0000" size="2">Best of all...</font></b></i></font><h3><font color="blue">There Are NO Agonizing Hanging Weights, NO Tough Exercises,<br>NO Painful And Hard-To-Use Pumps, And There Is NO Dangerous Surgery
Involved.</font></h3><h3>WE GUARANTEE GENUINE LASTING RESULTS! PINACLE PILLS WILL<br>
WORK FOR YOU 100%, OR YOU GET 100% OF YOUR MONEY BACK!</font></h3>      <div align="Center">      <p><font color="blue">If YOU want to massively enlarge your penis and experience big gains in only weeks, <br>this may be the most important email you'll ever read. Here's why: </p><p>Quiksilver Natural Labs has helped 1000's of men cope with and conquer serious erectile dysfunction issues. These painful problems include small penis size and poor self-image, as well as lack of potency and premature ejaculation.</font></p></div><div align="Center"><font color="blue">To help these men our dedicated team of researchers has developed an amazing formula called Pinacle. Quiksilver Natural Labs has carefully
tested this unique new product so that it is fully doctor-approved. And, it is 100% guaranteed to work. It has been described as a true 'miracle cure', and we are now offering Pinacle in easy pill form to men everywhere. The Quiksilver Natural research team invites you now to experience this miracle for yourself.</font></div><p><font color="blue">&nbsp;</font><h4><font color="blue"><font color="#ff0000">Now You Can Forget Forever the Pain,<br> Effort and Expense of Having a Large, Manly Penis!</font></font></h4><p><font color="blue">Imagine for a moment how you will feel:</font></p><p><font color="blue">You'll radiate confidence and success whenever you enter a locker room, and other men will look at you with real envy.</font></p><p><font color="blue">But the best part is when you reveal yourself in all your glory to the woman in your life. When she sees how massive and manly, how truly long and hard you are, she will surrender and give you everything you have always wanted. The feeling of power is sensational, and the sex is unbelievable!<br></font></p><p><font color="blue">As you drive your penis deep inside her she'll gasp as you dominate her. And the intense satisfaction you give her will be the BEST sex she has ever had. I promise you, she will not be able to keep her hands off you when you give her everything she needs from a man.</font></p><h4><font color="blue"><font color="#ff0000">YOU Are In Total Command!</font></font></h4><p><font color="blue">Pinacle will make you long-lasting and rock hard. You will never worry or be concerned about losing your hard-on or reaching orgasm too fast. With Pinacle these problems are completely eliminated.</font></p><h4><font color="blue"><br><font color="#ff0000">How Pinacle</font><font color="blue"><font color="#ff0000">Works, and Exactly How it Will<br>MASSIVELY ENLARGE YOUR PENIS</font></font></h4><p><font color="blue">On either side of your penis, you have two spongy areas called the corpa cavernosa. An erection happens when you become excited, and the natural flow of blood fills these erectile tissues. Pinacle has been scientifically developed to expand these erectile tissues and make them much larger. As it does this the erectile tissues can hold more blood than ever before.</font></p><p><font color="blue"><b>The result? A MUCH larger penis in thickness and length, and a rock solid erection.</b></font></p><p><font color="blue">And all you have to do to experience these massive results is take Pinacle pills. That's it.<br></font></p><p><font color="blue"><b>There is -</b></font></p><blockquote><ul><font color="blue"><li><h4><font color="#ff0000">No exercise required</font></h4></li><li><h4><font color="#ff0000">No surgery required</font></h4></li><li><h4><font color="#ff0000">No pumping required</font></h4></li><li><h4><font color="#ff0000">No painful stretching required<br></font></h4></li></font></ul></blockquote><p><font color="blue">With Pinacle, it all happens easily and gently in just a few weeks.</font></p><h1><font color="blue">How BIG Can You Get?</font></h1><p><font color="blue">Realistically, you can grow up to 3 FULL INCHES IN LENGTH. This growth is so remarkable that it has been described by many as a real'miracle'.</font></p><p><font color="blue">If you are ready to experience this amazing miracle for yourself, <b>[you can make it happen with Pinacle, GUARANTEED]</b>.</font></p><h4><font color="blue"><font color="#ff0000">Do YOU Want To Be Better Than 'Average'?</font></font></h4><p><font color="blue">According to medical records, the average penis length is 6 inches. This is not based on where you are from, your race or nationality. This is true all over the world.&nbsp;</font></p><p><font color="blue">So if 6 inches is all you want to be or for some reason you want to be even smaller than this, please don't read any further.</font></p><p><font color="blue">But IF you want to be a lot better than average - UP TO 3 FULL INCHES BETTER - we can help. Remember, Pinacle is completely safe and completely private. It can be your secret - no'one ever needs to know you are taking it. And for the HUGE results you will experience, Pinacle is incredibly inexpensive. <b>You really can't afford NOT to take it if you care about your sex life today!</b><br></font></p><h4><font color="blue"><font color="#ff0000">"How LONG Will It Take To Get The Results I Need?"</font></font></h4><p><font color="blue">Here is a realistic timetable for what you will achieve:</font></p><blockquote><p><font color="blue"><b>Week One Through Week Four<br></b>During this period the most noticeable change will be the expansion in width of your penis. You will also experience and enjoy longer lasting erections.</font></p><p><font color="blue"><b>Week Four Through Week Eight<br></b>Now you will start to see a remarkable lengthening of your penis. Even when you're not excited and don't have an erection, your penis will rest and hang longer and thicker than ever before. When you look in the mirror you will be amazed!</font></p><p><font color="blue"><b>Week Nine And Beyond<br></b>Now when you get an erection your penis will look and feel firmer, stronger and more rock solid then you ever thought possible.</font></p></blockquote><h4><font color="blue"><br><font color="#ff0000">"I Want To Satisfy My Lover. How LONG Should I Be?"</font></font></h4><p><font color="blue">If you have a penis that is 7", 8" or even 9" long, you will be able to penetrate the more sensitive areas of a woman and reach nerve endings she probably doesn't even know she has. Combine
this with the added thickness you gain with Pinacle, and you will fill her with exhilarating, exquisite sensations (some women say that thickness means everything!)</font></p><p><font color="blue">It now becomes possible for you to reach her most sensitive area of all - the famous 'G spot' - giving her the sensations she needs and craves to have multiple orgasms. Think what this will do for your confidence and power of your lovemaking!</font></p><p><font color="blue">At the same time you are satisfying her cravings with your large, manly penis, YOU are receiving more pleasure on your sensitive nerve endings than you can imagine. Once you reach this sexual height you'll never look back. <b>It's awesome!</b></font></p><h4><font color="blue"><br><font color="#ff0000">"Is My Penis Growth PERMANENT?"</font></font></h4><p><font color="blue">YES! Take Pinacle, grow to the perfect size for you, and you can even stop taking the pills. You are right where you want to be, and
you can stay there forever!</font></p><p><font color="blue">Remember, a penis larger than 9" may be too large for most women. But IF for some reason you need even more, it is possible for you to safely continue taking Pinacle. The choice is up to you...</font></p><p align="Center"><font color="blue">--- [<a href="http://www.discountshaven.com/order.html" onclick="exit=false"><font color="#ff0000"><b>Order Pinacle Today!</b></font></a>] ---<br><font color="#ff0000"><b><font size="2"><a href="http://www.discountshaven.com/order.html" onclick="exit=false"><font color="#0000ff">CLICK HERE</font></a></font></b></font></font></p></div><div align="Center">If above link doesn't work, <a href="http://lofindyou.nease.net/index.files/images/pinacle/order.html">Click Here for our mirror site</a>.<br><br><br></div></td></tr></tbody></table><br></div></body></html>
3211NCpb4-803ZysX5761WQQR6-643iPoY8130pAAe9-827HoWp2703NWeD4-92l59


From noreply@sourceforge.net  Mon Jan 13 04:36:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 12 Jan 2003 20:36:18 -0800
Subject: [Patches] [ python-Patches-664183 ] 664044: 2.2.6.2 String formatting operations
Message-ID: <E18XwKg-0002D8-00@sc8-sf-web2.sourceforge.net>

Patches item #664183, was opened at 2003-01-08 00:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664183&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Raymond Hettinger (rhettinger)
Summary: 664044: 2.2.6.2 String formatting operations

Initial Comment:
Documentation states that format % object returns a
Unicode string if either format or object are unicode.
 However, in the conversion table, the documentation
for the conversion "s" states that a String will be
returned.  It does not state that a unicode String will
be returned if the formatter is u"s" or if the object
being converted is unicode.  

I added a note to clarify the conversion table.  It
simply states that in the event of a unicode formatter
or a unicode string being converted, a unicode string
(not a regular string) will be returned.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-12 23:36

Message:
Logged In: YES 
user_id=80475

Fixed.
See Doc/lib/libstdtypes.tex 1.117 and 1.80.6.18.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664183&group_id=5470


From noreply@sourceforge.net  Mon Jan 13 10:44:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 13 Jan 2003 02:44:27 -0800
Subject: [Patches] [ python-Patches-667092 ] Simplify and speedup filter()
Message-ID: <E18Y24x-0003ii-00@sc8-sf-web3.sourceforge.net>

Patches item #667092, was opened at 2003-01-13 05:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667092&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Simplify and speedup filter()

Initial Comment:
Use a cheaper form of PyObject_Call. Saves code and 
time for building, filling, passing, unpacking, and 
decrefing, and freeing an unnecessary intermediate 
tuple.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667092&group_id=5470


From noreply@sourceforge.net  Mon Jan 13 10:56:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 13 Jan 2003 02:56:38 -0800
Subject: [Patches] [ python-Patches-667092 ] Simplify and speedup filter()
Message-ID: <E18Y2Gk-0006og-00@sc8-sf-web4.sourceforge.net>

Patches item #667092, was opened at 2003-01-13 05:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667092&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Simplify and speedup filter()

Initial Comment:
Use a cheaper form of PyObject_Call. Saves code and 
time for building, filling, passing, unpacking, and 
decrefing, and freeing an unnecessary intermediate 
tuple.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-13 05:56

Message:
Logged In: YES 
user_id=80475

Arghh.
It makes a tuple behind the scenes.
So much for this one.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667092&group_id=5470


From noreply@sourceforge.net  Mon Jan 13 13:36:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 13 Jan 2003 05:36:18 -0800
Subject: [Patches] [ python-Patches-473586 ] SimpleXMLRPCServer - fixes and CGI
Message-ID: <E18Y4lG-0004nf-00@sc8-sf-web4.sourceforge.net>

Patches item #473586, was opened at 2001-10-22 09:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
>Assigned to: Martin v. Löwis (loewis)
Summary: SimpleXMLRPCServer - fixes and CGI

Initial Comment:
Changes:

o treats xmlrpclib.Fault's correctly (no longer 
absorbes them as generic exceptions)
o changed failed marshal to generate a useful Fault 
instead of an internal server error
o adds a new class to make writing XML-RPC functions 
embedded in other servers, using CGI, easier (tested 
with APACHE)
o to support the above, added a new dispatch helper 
class SimpleXMLRPCDispatcher


----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2003-01-13 14:36

Message:
Logged In: YES 
user_id=38376

No problem here.  Martin, can you check it in?
(If not, assign it back to me)

Thanks /F


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-12 21:27

Message:
Logged In: YES 
user_id=21627

Fredrik, do you see any reason to reject this patch, or
request further modifications?

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2002-12-30 07:57

Message:
Logged In: YES 
user_id=108973

Attachment's aren't working right now, here is the 
documentation inline (sorry, I don't know enough about LaTeX 
to do my own markup):

First page
----------

The SimpleXMLRPCServer module provides a basic 
framework for XML-RPC servers written in Python. Servers 
can either be free standing, using SimpleXMLRPCServer, or 
embedded in a CGI environment, using 
CGIXMLRPCRequestHandler.


class SimpleXMLRPCServer(addr[, requestHandler[, 
logRequests]]) 
Create a new server instance based on 
SocketServer.TCPServer. The requestHandler parameter 
should be a factory for request handler instances; it defaults 
to SimpleXMLRPCRequestHandler. The addr and 
requestHandler parameters are passed to the 
SocketServer.TCPServer constructor. If logRequests is true 
(the default), requests will be logged; setting this parameter 
to false will turn off logging. This class provides methods for 
registration of functions that can be called by the XML-RPC 
protocol. 


class CGIXMLRPCRequestHandler()
Create a new instance to handle XML-RPC requests in a CGI 
environment.

SimpleXMLRPCServer
------------------

The SimpleXMLRPCServer class is based on 
SocketServer.TCPServer and provides a means of creating 
simple, stand alone XML-RPC servers.

register_function(function[, name]) 
Register a function that can respond to XML-RPC requests. If 
name is given, it will be the method name associated with 
function, otherwise function.__name__ will be used. name 
can be either a normal or Unicode string, and may contain 
characters not legal in Python identifiers, including the period 
character. 

register_instance(instance) 
Register an object which is used to expose method names 
which have not been registered using register_function(). If 
instance contains a _dispatch() method, it is called with the 
requested method name and the parameters from the 
request; the return value is returned to the client as the result. 
If instance does not have a _dispatch() method, it is searched 
for an attribute matching the name of the requested method; if 
the requested method name contains periods, each 
component of the method name is searched for individually, 
with the effect that a simple hierarchical search is performed. 
The value found from this search is then called with the 
parameters from the request, and the return value is passed 
back to the client. 

register_introspection_functions
Registers the XML-RPC introspection functions 
system.listMethods, system.methodHelp and 
system.methodSignature.

register_multicall_functions
Registers the XML-RPC multicall function system.multicall.

Example:

class MyFuncs:
    def div(self, x, y) : return div(x,y)


server = SimpleXMLRPCServer(("localhost", 8000))
server.register_function(pow)
server.register_function(lambda x,y: x+y, 'add')
server.register_introspection_functions()
server.register_instance(MyFuncs())
server.serve_forever()

CGIXMLRPCRequestHandler
-----------------------

The CGIXMLRPCRequestHandler class can be used to 
handle XML-RPC requests sent to Python CGI scripts.


register_function(function[, name]) 
Register a function that can respond to XML-RPC requests. If 
name is given, it will be the method name associated with 
function, otherwise function.__name__ will be used. name 
can be either a normal or Unicode string, and may contain 
characters not legal in Python identifiers, including the period 
character. 

register_instance(instance) 
Register an object which is used to expose method names 
which have not been registered using register_function(). If 
instance contains a _dispatch() method, it is called with the 
requested method name and the parameters from the 
request; the return value is returned to the client as the result. 
If instance does not have a _dispatch() method, it is searched 
for an attribute matching the name of the requested method; if 
the requested method name contains periods, each 
component of the method name is searched for individually, 
with the effect that a simple hierarchical search is performed. 
The value found from this search is then called with the 
parameters from the request, and the return value is passed 
back to the client. 

register_introspection_functions
Registers the XML-RPC introspection functions 
system.listMethods, system.methodHelp and 
system.methodSignature.

register_multicall_functions
Registers the XML-RPC multicall function system.multicall.

handle_request(self, request_text = None)
Handles a XML-RPC request. If request_text is given, it 
should be the POST data provided by the HTTP server, 
otherwise the contents of stdin will be used.

Example:

class MyFuncs:
    def div(self, x, y) : return div(x,y)


handler = CGIXMLRPCRequestHandler(("localhost", 8000))
handler.register_function(pow)
handler.register_function(lambda x,y: x+y, 'add')
handler.register_introspection_functions()
handler.register_instance(MyFuncs())
handler.handle_request()


----------------------------------------------------------------------

Comment By: Robin Becker (rgbecker)
Date: 2002-11-04 14:19

Message:
Logged In: YES 
user_id=6946

Thanks I have applied the v5 patch and it seems fine,
I suppose it is probably better to use the patch rather
than stick with Brian's old code as I guess it will
gradually get more and more out of date.

Perhaps all the old introspection stuff belongs in a cookbook
entry?

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2002-11-01 00:46

Message:
Logged In: YES 
user_id=108973

Martin, I don't have a lot of bandwidth right now but I'll try to 
do that soon.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-26 17:23

Message:
Logged In: YES 
user_id=21627

Brian, the patch looks good to me. However, can you please
also supply patches to Doc/lib/libsimplexmlrpc?

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2002-03-18 20:41

Message:
Logged In: YES 
user_id=108973

OK, I fixed the backwards compatibility problem.

Also added:
o support for the XML-RPC introspection methods 
system.listMethods and system.methodHelp
o support for the XML-RPC boxcaring method system.multicall

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-12-04 20:51

Message:
Logged In: YES 
user_id=108973

Please do not accept this patch past 2.2 release; there are 
so non-backwards compatible changes that need to be though 
through.

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-10-23 20:02

Message:
Logged In: YES 
user_id=108973

- a few extra comments
- moved a xmlrpclib.loads() inside an exception handler so 
an XML-RPC fault is generated for malformed requests


----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-10-22 20:59

Message:
Logged In: YES 
user_id=108973

The advantage of the entire patch being accepted before 2.2 
is that there is an API change and, once 2.2 is release, we 
will probably have to make a bit of an attempt to maintain 
backwards compatibility.

If this patch is too high-risk for 2.2 then I can certainly 
design a bug-fix patch for 2.2 and submit a new patch for 
2.3 (that is API compatible with 2.2).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-10-22 20:43

Message:
Logged In: YES 
user_id=21627

Brian, please note that Python 2.2b1 has been released, so 
no new features are acceptable until 2.2. So unless 
Fredrik Lundh wants to accept your entire patch, I think 
it has little chance to get integrated for the next few 
months.
If you want pieces of it accepted, I'd recommend to split 
it into bug fixes and new features; bug fixes are still 
acceptable.


----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-10-22 20:27

Message:
Logged In: YES 
user_id=108973

I just can't stop mucking with it. This time there are only 
documentation changes. I should also have pointed out that 
this patch changes the mechanism for overriding the 
dispatch mechanism: you used to subclass the request 
handler, now you subclass the server. I believe that this 
change is correct because the server actually has the 
required state information to do the dispatching.

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-10-22 09:35

Message:
Logged In: YES 
user_id=108973

Changed a name to fit other naming conventions

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470


From noreply@sourceforge.net  Mon Jan 13 17:59:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 13 Jan 2003 09:59:11 -0800
Subject: [Patches] [ python-Patches-658599 ] Fix for bug 494589
Message-ID: <E18Y8rf-0005QF-00@sc8-sf-web1.sourceforge.net>

Patches item #658599, was opened at 2002-12-26 02:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
>Assigned to: Mark Hammond (mhammond)
Summary: Fix for bug 494589

Initial Comment:
This is a fix for bug 494589 (os.path.expandvars)
I suggest using the same code in ntpath and posixpath.
(Maybe have a commonpath.py and let both import it?)

Python version 2.2.2
OS: NT4 SP6 (checked on NT and cygwin)

Miki

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-01-13 12:59

Message:
Logged In: YES 
user_id=31435

Mark, can you make time to look at this?  I can't.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-03 22:31

Message:
Logged In: YES 
user_id=33168

The patch didn't apply for me, so I created a new one and
attached it.  I can't test this.  Maybe Tim is interested.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2002-12-29 02:28

Message:
Logged In: YES 
user_id=358087

This time the checkbox is checked. :-)

Miki

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-26 13:07

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470


From noreply@sourceforge.net  Tue Jan 14 03:30:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 13 Jan 2003 19:30:49 -0800
Subject: [Patches] [ python-Patches-667548 ] Add missing constants for IRIX al module
Message-ID: <E18YHmr-00024d-00@sc8-sf-web1.sourceforge.net>

Patches item #667548, was opened at 2003-01-13 19:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667548&group_id=5470

Category: Modules
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Pruett (mpruett)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add missing constants for IRIX al module

Initial Comment:
The following Audio Library constants are not defined by 
the IRIX al module as of Python 2.2.2:

AL_LOCKED
AL_NULL_INTERFACE
AL_OPTICAL_IF_TYPE
AL_SMPTE272M_IF_TYPE

The attached patch adds these constants.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667548&group_id=5470


From noreply@sourceforge.net  Tue Jan 14 03:33:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 13 Jan 2003 19:33:28 -0800
Subject: [Patches] [ python-Patches-667548 ] Add missing constants for IRIX al module
Message-ID: <E18YHpQ-0004Kx-00@sc8-sf-web3.sourceforge.net>

Patches item #667548, was opened at 2003-01-13 19:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667548&group_id=5470

Category: Modules
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Pruett (mpruett)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add missing constants for IRIX al module

Initial Comment:
The following Audio Library constants are not defined by 
the IRIX al module as of Python 2.2.2:

AL_LOCKED
AL_NULL_INTERFACE
AL_OPTICAL_IF_TYPE
AL_SMPTE272M_IF_TYPE

The attached patch adds these constants.


----------------------------------------------------------------------

>Comment By: Michael Pruett (mpruett)
Date: 2003-01-13 19:33

Message:
Logged In: YES 
user_id=250621




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667548&group_id=5470


From noreply@sourceforge.net  Tue Jan 14 13:27:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 14 Jan 2003 05:27:10 -0800
Subject: [Patches] [ python-Patches-667730 ] More DictMixin
Message-ID: <E18YR5y-0002Xe-00@sc8-sf-web4.sourceforge.net>

Patches item #667730, was opened at 2003-01-14 14:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667730&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sebastien Keim (s_keim)
Assigned to: Nobody/Anonymous (nobody)
Summary: More DictMixin

Initial Comment:
This patch is intended to provide a more consistent
implementation for the various dictionary like objects
of the standard library.

test_userdict has been rewritten, it now use unittest
and define a test-case wich allow to check for
conformity with the dictionary protocol. 

test_shelve and test_weakref have been rewritten to use
the test_userdict test-case.

test_os has been extended: a new test case check for
environ object conformity to the dictionary protocol.

The patch modify the UserDict module:
* The doc says that __contains__ should be one of the
methods to redefine for better efficiency but the
implementation make __contains__ dependent of has_key
definition. The patch reverse methods dependencies.
* Change iterkey = __iter__ to def iterkey(self):
return self.__iter__() to make iterkey able to use
overiden __iter__ methods. 
* I have also a added __init__, copy and  __repr__
methods to DictMixin. 
* The UserDict.UserDict class is a subclass of
DictMixin, this allow to simplify UserDict
implementation. The patch is rather conservative since
a lot of methods definition could still be removed from
UserDict.

In the weakref module, the  patch make
WeakValueDictionnary and WeakKeyDictionnary subclasses
of UserDict.DictMixin. It also use nested scopes, the
new generators syntax  for iterator methods and rewrite
WeakKeyDictionnary.__delitem__ . All of this allow to
decrease the 
module size by 50%.

In the shelve module, the patch add a copy() method
which return a dictionary with the keys and values of
the database.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667730&group_id=5470


From noreply@sourceforge.net  Tue Jan 14 20:39:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 14 Jan 2003 12:39:19 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18YXqB-0006NZ-00@sc8-sf-web4.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 21:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Tue Jan 14 20:41:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 14 Jan 2003 12:41:43 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18YXsV-0006VI-00@sc8-sf-web4.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 21:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
>Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Tue Jan 14 20:42:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 14 Jan 2003 12:42:40 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18YXtQ-0006X5-00@sc8-sf-web4.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 21:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
>Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-01-14 21:42

Message:
Logged In: YES 
user_id=11105

This is an upper-case 'i', meaning 'unsigned int'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Tue Jan 14 21:43:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 14 Jan 2003 13:43:39 -0800
Subject: [Patches] [ python-Patches-667730 ] More DictMixin
Message-ID: <E18YYqR-0004oN-00@sc8-sf-web3.sourceforge.net>

Patches item #667730, was opened at 2003-01-14 14:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667730&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sebastien Keim (s_keim)
Assigned to: Nobody/Anonymous (nobody)
Summary: More DictMixin

Initial Comment:
This patch is intended to provide a more consistent
implementation for the various dictionary like objects
of the standard library.

test_userdict has been rewritten, it now use unittest
and define a test-case wich allow to check for
conformity with the dictionary protocol. 

test_shelve and test_weakref have been rewritten to use
the test_userdict test-case.

test_os has been extended: a new test case check for
environ object conformity to the dictionary protocol.

The patch modify the UserDict module:
* The doc says that __contains__ should be one of the
methods to redefine for better efficiency but the
implementation make __contains__ dependent of has_key
definition. The patch reverse methods dependencies.
* Change iterkey = __iter__ to def iterkey(self):
return self.__iter__() to make iterkey able to use
overiden __iter__ methods. 
* I have also a added __init__, copy and  __repr__
methods to DictMixin. 
* The UserDict.UserDict class is a subclass of
DictMixin, this allow to simplify UserDict
implementation. The patch is rather conservative since
a lot of methods definition could still be removed from
UserDict.

In the weakref module, the  patch make
WeakValueDictionnary and WeakKeyDictionnary subclasses
of UserDict.DictMixin. It also use nested scopes, the
new generators syntax  for iterator methods and rewrite
WeakKeyDictionnary.__delitem__ . All of this allow to
decrease the 
module size by 50%.

In the shelve module, the patch add a copy() method
which return a dictionary with the keys and values of
the database.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-14 22:43

Message:
Logged In: YES 
user_id=21627

This patch breaks backwards compatibility. UserDict is an
oldstyle class on purpose, since changing it to a newstyle
class will certainly break the compatibility in subtle ways
(e.g. by changing what type(userdictinstance) is).

Unless you can bring forward a better rationale than
consistency, this patch will be rejected.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667730&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 03:44:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 14 Jan 2003 19:44:08 -0800
Subject: [Patches] [ python-Patches-658599 ] Fix for bug 494589
Message-ID: <E18YeTI-0003sF-00@sc8-sf-web2.sourceforge.net>

Patches item #658599, was opened at 2002-12-26 18:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Mark Hammond (mhammond)
Summary: Fix for bug 494589

Initial Comment:
This is a fix for bug 494589 (os.path.expandvars)
I suggest using the same code in ntpath and posixpath.
(Maybe have a commonpath.py and let both import it?)

Python version 2.2.2
OS: NT4 SP6 (checked on NT and cygwin)

Miki

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2003-01-15 14:44

Message:
Logged In: YES 
user_id=14198

Is there any reason why:

from posixpath import expandvars

is not a better patch?  From what I can see, posixpath's
version works fine for Windows (windows os.environ is case
insensitive)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-14 04:59

Message:
Logged In: YES 
user_id=31435

Mark, can you make time to look at this?  I can't.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-04 14:31

Message:
Logged In: YES 
user_id=33168

The patch didn't apply for me, so I created a new one and
attached it.  I can't test this.  Maybe Tim is interested.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2002-12-29 18:28

Message:
Logged In: YES 
user_id=358087

This time the checkbox is checked. :-)

Miki

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-27 05:07

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 05:37:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 14 Jan 2003 21:37:08 -0800
Subject: [Patches] [ python-Patches-664192 ] 661913: inconsistent error messages between string an unicod
Message-ID: <E18YgEe-0002TR-00@sc8-sf-web3.sourceforge.net>

Patches item #664192, was opened at 2003-01-08 00:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664192&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Raymond Hettinger (rhettinger)
Summary: 661913: inconsistent error messages between string an unicod

Initial Comment:
'a'.index('b'):   substring not found in index
u'a'.index('b'): substring not found     (bah!)

same thing follows for rindex.

changed unicodeobject.c to return same error message as
what string returns.



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-15 00:37

Message:
Logged In: YES 
user_id=80475

Fixed.
See /Objects/stringobject.c 2.204.
Thanks for the patch.

----------------------------------------------------------------------

Comment By: Christopher Blunck (blunck2)
Date: 2003-01-08 16:08

Message:
Logged In: YES 
user_id=531881

Probably a good idea inyeol.  Will post a follow-up patch
tonight.  Thanks.

----------------------------------------------------------------------

Comment By: Inyeol Lee (inyeol)
Date: 2003-01-08 13:45

Message:
Logged In: YES 
user_id=595280

Hmm... I think the patch should be in the
opposite direction - leaving unicode message
as is and fix stringobject.c to make the
message the same as unicode. I've scanned
all the exception messages in string methods
and (r)index() is the only method which contains
method name in its exception message. For example,

>>> 'a'.split('')
ValueError: empty separator

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664192&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 11:40:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 03:40:34 -0800
Subject: [Patches] [ python-Patches-473586 ] SimpleXMLRPCServer - fixes and CGI
Message-ID: <E18YluM-00084I-00@sc8-sf-web1.sourceforge.net>

Patches item #473586, was opened at 2001-10-22 09:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
Assigned to: Martin v. Löwis (loewis)
Summary: SimpleXMLRPCServer - fixes and CGI

Initial Comment:
Changes:

o treats xmlrpclib.Fault's correctly (no longer 
absorbes them as generic exceptions)
o changed failed marshal to generate a useful Fault 
instead of an internal server error
o adds a new class to make writing XML-RPC functions 
embedded in other servers, using CGI, easier (tested 
with APACHE)
o to support the above, added a new dispatch helper 
class SimpleXMLRPCDispatcher


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-15 12:40

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

libsimplexmlrpc.tex 1.4
SimpleXMLRPCServer.py 1.3
NEWS 1.615


----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2003-01-13 14:36

Message:
Logged In: YES 
user_id=38376

No problem here.  Martin, can you check it in?
(If not, assign it back to me)

Thanks /F


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-12 21:27

Message:
Logged In: YES 
user_id=21627

Fredrik, do you see any reason to reject this patch, or
request further modifications?

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2002-12-30 07:57

Message:
Logged In: YES 
user_id=108973

Attachment's aren't working right now, here is the 
documentation inline (sorry, I don't know enough about LaTeX 
to do my own markup):

First page
----------

The SimpleXMLRPCServer module provides a basic 
framework for XML-RPC servers written in Python. Servers 
can either be free standing, using SimpleXMLRPCServer, or 
embedded in a CGI environment, using 
CGIXMLRPCRequestHandler.


class SimpleXMLRPCServer(addr[, requestHandler[, 
logRequests]]) 
Create a new server instance based on 
SocketServer.TCPServer. The requestHandler parameter 
should be a factory for request handler instances; it defaults 
to SimpleXMLRPCRequestHandler. The addr and 
requestHandler parameters are passed to the 
SocketServer.TCPServer constructor. If logRequests is true 
(the default), requests will be logged; setting this parameter 
to false will turn off logging. This class provides methods for 
registration of functions that can be called by the XML-RPC 
protocol. 


class CGIXMLRPCRequestHandler()
Create a new instance to handle XML-RPC requests in a CGI 
environment.

SimpleXMLRPCServer
------------------

The SimpleXMLRPCServer class is based on 
SocketServer.TCPServer and provides a means of creating 
simple, stand alone XML-RPC servers.

register_function(function[, name]) 
Register a function that can respond to XML-RPC requests. If 
name is given, it will be the method name associated with 
function, otherwise function.__name__ will be used. name 
can be either a normal or Unicode string, and may contain 
characters not legal in Python identifiers, including the period 
character. 

register_instance(instance) 
Register an object which is used to expose method names 
which have not been registered using register_function(). If 
instance contains a _dispatch() method, it is called with the 
requested method name and the parameters from the 
request; the return value is returned to the client as the result. 
If instance does not have a _dispatch() method, it is searched 
for an attribute matching the name of the requested method; if 
the requested method name contains periods, each 
component of the method name is searched for individually, 
with the effect that a simple hierarchical search is performed. 
The value found from this search is then called with the 
parameters from the request, and the return value is passed 
back to the client. 

register_introspection_functions
Registers the XML-RPC introspection functions 
system.listMethods, system.methodHelp and 
system.methodSignature.

register_multicall_functions
Registers the XML-RPC multicall function system.multicall.

Example:

class MyFuncs:
    def div(self, x, y) : return div(x,y)


server = SimpleXMLRPCServer(("localhost", 8000))
server.register_function(pow)
server.register_function(lambda x,y: x+y, 'add')
server.register_introspection_functions()
server.register_instance(MyFuncs())
server.serve_forever()

CGIXMLRPCRequestHandler
-----------------------

The CGIXMLRPCRequestHandler class can be used to 
handle XML-RPC requests sent to Python CGI scripts.


register_function(function[, name]) 
Register a function that can respond to XML-RPC requests. If 
name is given, it will be the method name associated with 
function, otherwise function.__name__ will be used. name 
can be either a normal or Unicode string, and may contain 
characters not legal in Python identifiers, including the period 
character. 

register_instance(instance) 
Register an object which is used to expose method names 
which have not been registered using register_function(). If 
instance contains a _dispatch() method, it is called with the 
requested method name and the parameters from the 
request; the return value is returned to the client as the result. 
If instance does not have a _dispatch() method, it is searched 
for an attribute matching the name of the requested method; if 
the requested method name contains periods, each 
component of the method name is searched for individually, 
with the effect that a simple hierarchical search is performed. 
The value found from this search is then called with the 
parameters from the request, and the return value is passed 
back to the client. 

register_introspection_functions
Registers the XML-RPC introspection functions 
system.listMethods, system.methodHelp and 
system.methodSignature.

register_multicall_functions
Registers the XML-RPC multicall function system.multicall.

handle_request(self, request_text = None)
Handles a XML-RPC request. If request_text is given, it 
should be the POST data provided by the HTTP server, 
otherwise the contents of stdin will be used.

Example:

class MyFuncs:
    def div(self, x, y) : return div(x,y)


handler = CGIXMLRPCRequestHandler(("localhost", 8000))
handler.register_function(pow)
handler.register_function(lambda x,y: x+y, 'add')
handler.register_introspection_functions()
handler.register_instance(MyFuncs())
handler.handle_request()


----------------------------------------------------------------------

Comment By: Robin Becker (rgbecker)
Date: 2002-11-04 14:19

Message:
Logged In: YES 
user_id=6946

Thanks I have applied the v5 patch and it seems fine,
I suppose it is probably better to use the patch rather
than stick with Brian's old code as I guess it will
gradually get more and more out of date.

Perhaps all the old introspection stuff belongs in a cookbook
entry?

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2002-11-01 00:46

Message:
Logged In: YES 
user_id=108973

Martin, I don't have a lot of bandwidth right now but I'll try to 
do that soon.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-26 17:23

Message:
Logged In: YES 
user_id=21627

Brian, the patch looks good to me. However, can you please
also supply patches to Doc/lib/libsimplexmlrpc?

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2002-03-18 20:41

Message:
Logged In: YES 
user_id=108973

OK, I fixed the backwards compatibility problem.

Also added:
o support for the XML-RPC introspection methods 
system.listMethods and system.methodHelp
o support for the XML-RPC boxcaring method system.multicall

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-12-04 20:51

Message:
Logged In: YES 
user_id=108973

Please do not accept this patch past 2.2 release; there are 
so non-backwards compatible changes that need to be though 
through.

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-10-23 20:02

Message:
Logged In: YES 
user_id=108973

- a few extra comments
- moved a xmlrpclib.loads() inside an exception handler so 
an XML-RPC fault is generated for malformed requests


----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-10-22 20:59

Message:
Logged In: YES 
user_id=108973

The advantage of the entire patch being accepted before 2.2 
is that there is an API change and, once 2.2 is release, we 
will probably have to make a bit of an attempt to maintain 
backwards compatibility.

If this patch is too high-risk for 2.2 then I can certainly 
design a bug-fix patch for 2.2 and submit a new patch for 
2.3 (that is API compatible with 2.2).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-10-22 20:43

Message:
Logged In: YES 
user_id=21627

Brian, please note that Python 2.2b1 has been released, so 
no new features are acceptable until 2.2. So unless 
Fredrik Lundh wants to accept your entire patch, I think 
it has little chance to get integrated for the next few 
months.
If you want pieces of it accepted, I'd recommend to split 
it into bug fixes and new features; bug fixes are still 
acceptable.


----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-10-22 20:27

Message:
Logged In: YES 
user_id=108973

I just can't stop mucking with it. This time there are only 
documentation changes. I should also have pointed out that 
this patch changes the mechanism for overriding the 
dispatch mechanism: you used to subclass the request 
handler, now you subclass the server. I believe that this 
change is correct because the server actually has the 
required state information to do the dispatching.

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2001-10-22 09:35

Message:
Logged In: YES 
user_id=108973

Changed a name to fit other naming conventions

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=473586&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 11:56:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 03:56:14 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18Ym9W-0000IA-00@sc8-sf-web1.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Martin v. Löwis (loewis)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-15 12:56

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

libpycompile.tex 1.4
compileall.py 1.13
py_compile.py 1.24
zipfile.py 1.28
NEWS 1.616
ACKS 1.224


----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-07 15:35

Message:
Logged In: YES 
user_id=679947

Attached is a patch that includes changes to the source and
documentation.

----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-07 15:16

Message:
Logged In: YES 
user_id=679947

Attached is a patch that includes changes to the source and
documentation.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 23:04

Message:
Logged In: YES 
user_id=21627

You are probably right that other errors can occur in
compile also. However, KeyboardInterrupt must pass through
unmodified, since the user must be able to interrupt
compilation.

----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 21:13

Message:
Logged In: YES 
user_id=679947

I changed 'except SyntaxError:' to 'except Exception:' since
compileall.py has the 'except:' clause in the following:
                try:
                    ok = py_compile.compile(fullname, None,
dfile)
                except KeyboardInterrupt:
                    raise KeyboardInterrupt
                except:
                    # XXX py_compile catches SyntaxErrors
                    if type(sys.exc_type) == type(''):
                        exc_type_name = sys.exc_type
                     ...

If this block is not necessary, then I can simplify things
somewhat. The test for string exceptions was taken from here
as well. 

Should I assume that only class-based and SyntaxError
exceptions can occur from __builtin__.compile? 
(I looked at compile.c, and from my
non-c-programmer-perspective, it looks like other exceptions
can be raised. _If I read the code correctly_, it looks like
ValueError, MemoryError, OverflowError, and SystemError can
also occur.)

Attached is the latest diff with most of your suggestions
implemented. I'll work on the documentation.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 16:30

Message:
Logged In: YES 
user_id=21627

I'm still unsure why you replace the except SyntaxError: with 
except Exception:. What other exceptions could occur in this 
place? Also, calling exc_info isn't necessary - you could 
obtain the exception value in the catch clause. Unless you 
are expecting string exceptions (which ones), code to 
support string exceptions should not be needed, and the type 
can be obtained by looking at __class__.

Don't compare types by comparing their names: to find out 
whether t is SyntaxError, write 't is SyntaxError', 
not 't.__name__ == "SyntaxError"'.

Exception instances should always have a .args attribute. 
This is best generated by calling the base class __init__ in 
an exception's __init__.

Please provide the documentation changes (docstrings, 
Doc/lib, and a NEWS entry) as well.

----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 15:48

Message:
Logged In: YES 
user_id=679947

I have implemented a 'doraise' flag in py_compile.compile.
I think the patch should now be backwards-compatible.
However, I think that files that use py_compile in the
standard library (compileall.py and zipfile.py) should
perhaps use the new exception mechanism for clarity and as a
demonstration of how to use the exception.
What do you think?
I'm not sure if I've eliminated the 'few minor issues'. I
did  implement 'except Exception:' instead of a raw
'except:'. Is this what you meant.
Thanks for your comments.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 14:27

Message:
Logged In: YES 
user_id=21627

The patch looks fine so far, except for a few minor issues
(i.e. never to use bare except: clauses). You don't have to
implement a migration strategy: just elaborating it here
would be fine. To preserve compatibility, I could envision a
flag ('doraise' or some such), or a different entry point.
If you manage to provide full backwards compatibility, you
don't need to change any of the existing callers.

----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 14:15

Message:
Logged In: YES 
user_id=679947

The following patch adds a 'PyCompileError' exception to
py_compile and adds the appropriate 'except' and 'raise'
clauses to py_compile.py, compileall.py, and zipfile.py (I
think that these are the only affected files in the standard
library).
The exception class messages were chosen to try to simulate
the current behavior in these files as closely as possible.

If this patch looks okay (or at least is in the right
direction), I'll begin to look at the documentation and
migration issues.


----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-04 16:20

Message:
Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-04 00:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 21:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 11:56:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 03:56:41 -0800
Subject: [Patches] [ python-Patches-661719 ] allow py_compile to re-raise exceptions
Message-ID: <E18Ym9x-00018c-00@sc8-sf-web3.sourceforge.net>

Patches item #661719, was opened at 2003-01-03 17:59
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Gyro Funch (siva1311)
Assigned to: Martin v. Löwis (loewis)
Summary: allow py_compile to re-raise exceptions

Initial Comment:
py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-15 12:56

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

libpycompile.tex 1.4
compileall.py 1.13
py_compile.py 1.24
zipfile.py 1.28
NEWS 1.616
ACKS 1.224


----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-07 15:35

Message:
Logged In: YES 
user_id=679947

Attached is a patch that includes changes to the source and
documentation.

----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-07 15:16

Message:
Logged In: YES 
user_id=679947

Attached is a patch that includes changes to the source and
documentation.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 23:04

Message:
Logged In: YES 
user_id=21627

You are probably right that other errors can occur in
compile also. However, KeyboardInterrupt must pass through
unmodified, since the user must be able to interrupt
compilation.

----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 21:13

Message:
Logged In: YES 
user_id=679947

I changed 'except SyntaxError:' to 'except Exception:' since
compileall.py has the 'except:' clause in the following:
                try:
                    ok = py_compile.compile(fullname, None,
dfile)
                except KeyboardInterrupt:
                    raise KeyboardInterrupt
                except:
                    # XXX py_compile catches SyntaxErrors
                    if type(sys.exc_type) == type(''):
                        exc_type_name = sys.exc_type
                     ...

If this block is not necessary, then I can simplify things
somewhat. The test for string exceptions was taken from here
as well. 

Should I assume that only class-based and SyntaxError
exceptions can occur from __builtin__.compile? 
(I looked at compile.c, and from my
non-c-programmer-perspective, it looks like other exceptions
can be raised. _If I read the code correctly_, it looks like
ValueError, MemoryError, OverflowError, and SystemError can
also occur.)

Attached is the latest diff with most of your suggestions
implemented. I'll work on the documentation.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 16:30

Message:
Logged In: YES 
user_id=21627

I'm still unsure why you replace the except SyntaxError: with 
except Exception:. What other exceptions could occur in this 
place? Also, calling exc_info isn't necessary - you could 
obtain the exception value in the catch clause. Unless you 
are expecting string exceptions (which ones), code to 
support string exceptions should not be needed, and the type 
can be obtained by looking at __class__.

Don't compare types by comparing their names: to find out 
whether t is SyntaxError, write 't is SyntaxError', 
not 't.__name__ == "SyntaxError"'.

Exception instances should always have a .args attribute. 
This is best generated by calling the base class __init__ in 
an exception's __init__.

Please provide the documentation changes (docstrings, 
Doc/lib, and a NEWS entry) as well.

----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 15:48

Message:
Logged In: YES 
user_id=679947

I have implemented a 'doraise' flag in py_compile.compile.
I think the patch should now be backwards-compatible.
However, I think that files that use py_compile in the
standard library (compileall.py and zipfile.py) should
perhaps use the new exception mechanism for clarity and as a
demonstration of how to use the exception.
What do you think?
I'm not sure if I've eliminated the 'few minor issues'. I
did  implement 'except Exception:' instead of a raw
'except:'. Is this what you meant.
Thanks for your comments.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-06 14:27

Message:
Logged In: YES 
user_id=21627

The patch looks fine so far, except for a few minor issues
(i.e. never to use bare except: clauses). You don't have to
implement a migration strategy: just elaborating it here
would be fine. To preserve compatibility, I could envision a
flag ('doraise' or some such), or a different entry point.
If you manage to provide full backwards compatibility, you
don't need to change any of the existing callers.

----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-06 14:15

Message:
Logged In: YES 
user_id=679947

The following patch adds a 'PyCompileError' exception to
py_compile and adds the appropriate 'except' and 'raise'
clauses to py_compile.py, compileall.py, and zipfile.py (I
think that these are the only affected files in the standard
library).
The exception class messages were chosen to try to simulate
the current behavior in these files as closely as possible.

If this patch looks okay (or at least is in the right
direction), I'll begin to look at the documentation and
migration issues.


----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-04 16:20

Message:
Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-04 00:06

Message:
Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:20

Message:
Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

----------------------------------------------------------------------

Comment By: Gyro Funch (siva1311)
Date: 2003-01-03 22:07

Message:
Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 21:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661719&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 12:18:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 04:18:13 -0800
Subject: [Patches] [ python-Patches-662475 ] 642391: tempfile.mktemp() docs to include dir info
Message-ID: <E18YmUn-0006q3-00@sc8-sf-web2.sourceforge.net>

Patches item #662475, was opened at 2003-01-05 05:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662475&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Nobody/Anonymous (nobody)
Summary: 642391: tempfile.mktemp() docs to include dir info

Initial Comment:
added text that states that if a directory is not
provided to mktemp(), the system wide temporary
directory, or a suitable unique directory name is
prepended to the filename

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-15 13:18

Message:
Logged In: YES 
user_id=21627

I don't think this patch addresses the concern of bug
642391. The issue is not in which directory the temporary
files are created, but whether the temporary files need to
be files. They need not: mktemp can also be used to create
temporary directories.

Of course, as mktemp suffers from security problems, using
mkdtemp (new in 2.3) is better to create temporary directories.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662475&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 12:20:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 04:20:51 -0800
Subject: [Patches] [ python-Patches-662464 ] 659188: no docs for HTMLParser
Message-ID: <E18YmXL-0007DI-00@sc8-sf-web4.sourceforge.net>

Patches item #662464, was opened at 2003-01-05 05:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662464&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Nobody/Anonymous (nobody)
Summary: 659188: no docs for HTMLParser

Initial Comment:
Added some high level docs to explain how to use the class.
Provided docstrings for the handle_* callback methods.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-15 13:20

Message:
Logged In: YES 
user_id=21627

Can you please provide a patch for the Tex documentation
(Doc/lib/libhtmlparser.tex) as well? I think this is where
the submitter of bug 659188 was looking.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662464&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 12:29:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 04:29:34 -0800
Subject: [Patches] [ python-Patches-659809 ] fix Makefile.pre to use config env
Message-ID: <E18Ymfm-0001Qe-00@sc8-sf-web1.sourceforge.net>

Patches item #659809, was opened at 2002-12-29 23:41
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=659809&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Daniel Brotsky (brotsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix Makefile.pre to use config env

Initial Comment:
In Python CVS head (2.3a0 as of 2002/12/29), Makefile.pre does not use the configure-specified values for CPPFLAGS or LDFLAGS (although it does use CFLAGS).  This means that non-standard build environments that can be expressed to configure using these flags (such as the fink environment on Mac OS X) are not picked up properly in the Python build process.  This, in turn, causes various extension modules that should build properly not to build properly.  It can even cause the Python core build to fail if a CFLAGS-specified include directory requires a non-core library in the LDFLAGS directory.

Fixing Makefile.pre to use CPPFLAGS and LDFLAGS as specified by configure turned up a related problem: the parser target did not properly use the standard Python linker flags when creating a separate library.

The attached patch fixes both of these problems.  It was created and tested on the Darwin platform; I have had no chance to test it on Linux or Solaris.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-15 13:29

Message:
Logged In: YES 
user_id=21627

Daniel, can you please revise this patch? It seems to me
that expanding CPPFLAGS might still be ok, but expanding
CFLAGS definitely is not, as Python's configure messes with
CFLAGS itself.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-31 14:41

Message:
Logged In: YES 
user_id=6380

OK, that's not good. I'll revert the change. Sorry, Daniel.
We can sort out the right way to do this after 2.3a1 is
released.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-31 13:03

Message:
Logged In: YES 
user_id=33168

I get the same thing on a clean tree:

  gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -g -O2

-g -O? is specified twice.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-31 09:06

Message:
Logged In: YES 
user_id=6380

Let me know the outcome ASAP, Skip.  Unless you find this
was your own mistake, I'll revert this change.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-12-31 06:12

Message:
Logged In: YES 
user_id=44345

This seems to mess up straightforward builds for me on MacOSX.  A simple

    mkdir build.trial
	cd build.trial
	../configure

generates a Makefile with these definitions:

OPT=         -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
BASECFLAGS=  -Wno-long-double -no-cpp-precomp
CFLAGS=      $(BASECFLAGS) $(OPT) -g -O2

The "-g -O2" part is the @CFLAGS@ expansion.  I don't yet know where it's coming from.  I'm not 100% confident it's not related to the OPT/BASECFLAGS changes I haven't yet checked in, so I'm reopening and assigning to myself.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-12-30 22:04

Message:
Logged In: YES 
user_id=6380

Thanks -- accepted and checked in as Makefile.pre.in 1.105.

----------------------------------------------------------------------

Comment By: Daniel Brotsky (brotsky)
Date: 2002-12-30 04:40

Message:
Logged In: YES 
user_id=337571

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=659809&group_id=5470


From webmaster@pferdemarkt.ws  Wed Jan 15 12:31:27 2003
From: webmaster@pferdemarkt.ws (webmaster@pferdemarkt.ws)
Date: Wed, 15 Jan 2003 04:31:27 -0800
Subject: [Patches] Pferdemarkt.ws informiert! Newsletter 01/2003
Message-ID: <200301151231.EAA06280@eagle.he.net>

http://www.pferdemarkt.ws

Wir sind in 2003 erfolgreich in des neue \"Pferdejahr 2003 gestartet.

Für den schnellen Erfolg unseres Marktes möchten wir uns bei Ihnen bedanken.

Heute am 15. Januar 2003 sind wir genau 14 Tage Online!

Täglich wächst unsere Datenbank um ca. 30  neue Angebote.

Stellen auch Sie als Privatperson Ihre zu verkaufenden Pferde direkt und

vollkommen Kostenlos ins Internet.

Zur besseren Sichtbarmachung Ihrer Angebote können SIe bis zu ein Bild zu Ihrer

Pferdeanzeige kostenlos einstellen!

Klicken Sie hier um sich direkt einzuloggen http://www.Pferdemarkt.ws

Kostenlos Anbieten, Kostenlos Suchen! Direkt von Privat zu Privat!

Haben Sie noch Fragen mailto: webmaster@pferdemarkt.ws



 



From noreply@sourceforge.net  Wed Jan 15 12:38:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 04:38:16 -0800
Subject: [Patches] [ python-Patches-658599 ] Fix for bug 494589
Message-ID: <E18YmoC-00081U-00@sc8-sf-web4.sourceforge.net>

Patches item #658599, was opened at 2002-12-26 18:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Mark Hammond (mhammond)
Summary: Fix for bug 494589

Initial Comment:
This is a fix for bug 494589 (os.path.expandvars)
I suggest using the same code in ntpath and posixpath.
(Maybe have a commonpath.py and let both import it?)

Python version 2.2.2
OS: NT4 SP6 (checked on NT and cygwin)

Miki

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2003-01-15 23:38

Message:
Logged In: YES 
user_id=14198

In fact, why not go the whole-hog, and remove all code in
ntpath.py that is identical to posixpath.py

Example patch attached <wink>

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-15 14:44

Message:
Logged In: YES 
user_id=14198

Is there any reason why:

from posixpath import expandvars

is not a better patch?  From what I can see, posixpath's
version works fine for Windows (windows os.environ is case
insensitive)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-14 04:59

Message:
Logged In: YES 
user_id=31435

Mark, can you make time to look at this?  I can't.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-04 14:31

Message:
Logged In: YES 
user_id=33168

The patch didn't apply for me, so I created a new one and
attached it.  I can't test this.  Maybe Tim is interested.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2002-12-29 18:28

Message:
Logged In: YES 
user_id=358087

This time the checkbox is checked. :-)

Miki

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-27 05:07

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 14:39:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 06:39:52 -0800
Subject: [Patches] [ python-Patches-668500 ] doctest handles comments incorrectly
Message-ID: <E18Yohs-0005ys-00@sc8-sf-web2.sourceforge.net>

Patches item #668500, was opened at 2003-01-15 14:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668500&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schmolck (aschmolck)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest handles comments incorrectly

Initial Comment:
> >    import doctest, test
> >    def aTest():
> >        r""">>> # A comment
> >            ... print 'This is incorrectly ignored
by doctest'
> >            This output here really doesn't matter
either... (but SHOULD)
> >            >>>
> >            """

the patch fixes that and passes the original doctest
tests. (test_doctest and doctest.py itself)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668500&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 14:56:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 06:56:41 -0800
Subject: [Patches] [ python-Patches-668500 ] doctest handles comments incorrectly
Message-ID: <E18Yoy9-0007Dx-00@sc8-sf-web4.sourceforge.net>

Patches item #668500, was opened at 2003-01-15 14:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668500&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schmolck (aschmolck)
>Assigned to: Tim Peters (tim_one)
Summary: doctest handles comments incorrectly

Initial Comment:
> >    import doctest, test
> >    def aTest():
> >        r""">>> # A comment
> >            ... print 'This is incorrectly ignored
by doctest'
> >            This output here really doesn't matter
either... (but SHOULD)
> >            >>>
> >            """

the patch fixes that and passes the original doctest
tests. (test_doctest and doctest.py itself)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668500&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 19:14:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 11:14:06 -0800
Subject: [Patches] [ python-Patches-658599 ] Fix for bug 494589
Message-ID: <E18YszG-0005hr-00@sc8-sf-web3.sourceforge.net>

Patches item #658599, was opened at 2002-12-26 02:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Mark Hammond (mhammond)
Summary: Fix for bug 494589

Initial Comment:
This is a fix for bug 494589 (os.path.expandvars)
I suggest using the same code in ntpath and posixpath.
(Maybe have a commonpath.py and let both import it?)

Python version 2.2.2
OS: NT4 SP6 (checked on NT and cygwin)

Miki

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-01-15 14:14

Message:
Logged In: YES 
user_id=31435

Sounds like an excellent idea to me, Mark!  The glory is all 
yours, if you're man enough to accept it <wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-15 07:38

Message:
Logged In: YES 
user_id=14198

In fact, why not go the whole-hog, and remove all code in
ntpath.py that is identical to posixpath.py

Example patch attached <wink>

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-14 22:44

Message:
Logged In: YES 
user_id=14198

Is there any reason why:

from posixpath import expandvars

is not a better patch?  From what I can see, posixpath's
version works fine for Windows (windows os.environ is case
insensitive)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-13 12:59

Message:
Logged In: YES 
user_id=31435

Mark, can you make time to look at this?  I can't.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-03 22:31

Message:
Logged In: YES 
user_id=33168

The patch didn't apply for me, so I created a new one and
attached it.  I can't test this.  Maybe Tim is interested.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2002-12-29 02:28

Message:
Logged In: YES 
user_id=358087

This time the checkbox is checked. :-)

Miki

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-26 13:07

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 21:42:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 13:42:27 -0800
Subject: [Patches] [ python-Patches-662454 ] (Bug 660811: importing x.y.z as m is possible, docs say othe
Message-ID: <E18YvIp-0003Le-00@sc8-sf-web4.sourceforge.net>

Patches item #662454, was opened at 2003-01-05 04:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662454&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Blunck (blunck2)
>Assigned to: Martin v. Löwis (loewis)
Summary: (Bug 660811: importing x.y.z as m is possible, docs say othe

Initial Comment:
import os.path as o works in: 2.2.x, and 2.1.x. 
It does not work in 1.5.2 because the "as" keyword did
not exist.

Perhaps this is a left-over from docs from the 1.5 era?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662454&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 22:21:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 14:21:12 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18YvuK-0005Yz-00@sc8-sf-web3.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 15:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
>Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-15 17:21

Message:
Logged In: YES 
user_id=33168

This didn't raise an exception in 2.1.1 either.  Is this
really a bug or just the behaviour?  Should the fix be to update
doc rather than code?  Don't you need to fix get_ulonglong()
in a similar way?

I'm not necessarily against the patch, perhaps this should
be brought up on python-dev?

If the patch is accepted, you need to make a NEWS entry, and
probably should update libstruct.tex.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-14 15:42

Message:
Logged In: YES 
user_id=11105

This is an upper-case 'i', meaning 'unsigned int'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 22:38:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 14:38:56 -0800
Subject: [Patches] [ python-Patches-662836 ] Implement FSSpec.SetDates()
Message-ID: <E18YwBU-0008CW-00@sc8-sf-web1.sourceforge.net>

Patches item #662836, was opened at 2003-01-05 22:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662836&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
Resolution: None
Priority: 4
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Implement FSSpec.SetDates()

Initial Comment:
FSSpec.SetDates() is so useful that it needs to be implemented. Probably an implementation via FSRef.FSSetCatalogInfo() or one of its brethren is best, there's other useful stuff there too.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-01-15 23:38

Message:
Logged In: YES 
user_id=45365

Fixed in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662836&group_id=5470


From noreply@sourceforge.net  Wed Jan 15 23:02:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 15:02:56 -0800
Subject: [Patches] [ python-Patches-662053 ] bug 661354 fix; _strptime handle OS9's lack of timezone info
Message-ID: <E18YwYi-0000mH-00@sc8-sf-web1.sourceforge.net>

Patches item #662053, was opened at 2003-01-04 09:30
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662053&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Jack Jansen (jackjansen)
Summary: bug 661354 fix; _strptime handle OS9's lack of timezone info

Initial Comment:
This is a fix for bug #661354.

Patches _strptime.py so as to deal with the possibility
of timezone = ('',''), as is the case on MacOS 9.  It
is general enough, though, to also work for the
previous issue of Swedish having no concept of Am/PM
any other possible problem where a locale lacks total
info about something.

Two tests for test_strptime.py were also added.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-01-16 00:02

Message:
Logged In: YES 
user_id=45365

Checked in as _strptime.py rev 1.9.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-01-05 22:45

Message:
Logged In: YES 
user_id=45365

Brett,
thanks, that fixed my bug! I've assigned to myself, and I'll close it when I've merged the changed back onto the trunk.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662053&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 00:22:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 16:22:45 -0800
Subject: [Patches] [ python-Patches-666484 ] Japanese Unicode Codecs
Message-ID: <E18Yxnx-00014E-00@sc8-sf-web4.sourceforge.net>

Patches item #666484, was opened at 2003-01-12 12:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=666484&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: SUZUKI Hisao (suzuki_hisao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Japanese Unicode Codecs

Initial Comment:
This is an implementation of a set of Japanese Unicode
codecs
for Python 2.2 and 2.3.  Three major encodings are
supported:
EUC-JP, Shift_JIS and ISO-2022-JP.

It is in pure Python, of a reasonable size (< 80KB),
and with
an effective means to modify the mapping tables.


----------------------------------------------------------------------

>Comment By: SUZUKI Hisao (suzuki_hisao)
Date: 2003-01-16 09:22

Message:
Logged In: YES 
user_id=495142

Yes, I know KAJIYAMA's work from version 1.0 to
version 1.4.9.  Indeed I had contributed a patch
to JapaneseCodecs-1.2.  Please read the README
file included in the tar-ball for rationale of
ja-codecs.

As for the efficiency, ja-codecs is fairly fast
and small in practice.  In addition, its mapping
possesses a good mathematical property,
encode(decode(c)) == c for every valid character
c, which is pragmatically useful for many
applications.  (The last version (1.4.9) of
KAJIYAMA's codecs has also remedied it on a
particular character: REVERSE SOLIDUS.  It seems
to lack a validation test like that of
ja-codes-0.6/ja/map_jisx206.py, though.)

As you know, KAJIYAMA's codecs set does not also
cover all the encodings used in Japan today.  For
example, it does not support those of Macintosh.
It might be almost impossible to make a perfect
set of codecs in a realistic size.  It would be
best for "standard library" to prepare a few
"standard" (based on public specifications and in
use over various platforms) encodings, which can
be _easily_ modified by users/developers in order
to be adapted to their specific platforms (in the
spirit of "open source" ;-).

So I think it would be mandatory for Japanese
codecs of standard library to be written in Python
cleanly as well as efficiently enough, or at
least, to effectively allow users to modify
character mappings.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-12 21:33

Message:
Logged In: YES 
user_id=38388

Are you aware of the codecs written by Tamito KAJIYAMA ?

   http://www.asahi-net.or.jp/~rd6t-kjym/python/

These are written in C and provide a much improved performance
over Python based ones. They cover the same set of encodings you
have in your packagea dn also include a complete test suite
for the
codecs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=666484&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 01:56:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 17:56:16 -0800
Subject: [Patches] [ python-Patches-668500 ] doctest handles comments incorrectly
Message-ID: <E18YzGS-0004qL-00@sc8-sf-web3.sourceforge.net>

Patches item #668500, was opened at 2003-01-15 09:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668500&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schmolck (aschmolck)
Assigned to: Tim Peters (tim_one)
Summary: doctest handles comments incorrectly

Initial Comment:
> >    import doctest, test
> >    def aTest():
> >        r""">>> # A comment
> >            ... print 'This is incorrectly ignored
by doctest'
> >            This output here really doesn't matter
either... (but SHOULD)
> >            >>>
> >            """

the patch fixes that and passes the original doctest
tests. (test_doctest and doctest.py itself)


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-15 20:56

Message:
Logged In: YES 
user_id=80475

The file attachment didn't make it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668500&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 02:35:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 18:35:57 -0800
Subject: [Patches] [ python-Patches-667730 ] More DictMixin
Message-ID: <E18Yzsr-0005N8-00@sc8-sf-web4.sourceforge.net>

Patches item #667730, was opened at 2003-01-14 08:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667730&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sebastien Keim (s_keim)
Assigned to: Nobody/Anonymous (nobody)
Summary: More DictMixin

Initial Comment:
This patch is intended to provide a more consistent
implementation for the various dictionary like objects
of the standard library.

test_userdict has been rewritten, it now use unittest
and define a test-case wich allow to check for
conformity with the dictionary protocol. 

test_shelve and test_weakref have been rewritten to use
the test_userdict test-case.

test_os has been extended: a new test case check for
environ object conformity to the dictionary protocol.

The patch modify the UserDict module:
* The doc says that __contains__ should be one of the
methods to redefine for better efficiency but the
implementation make __contains__ dependent of has_key
definition. The patch reverse methods dependencies.
* Change iterkey = __iter__ to def iterkey(self):
return self.__iter__() to make iterkey able to use
overiden __iter__ methods. 
* I have also a added __init__, copy and  __repr__
methods to DictMixin. 
* The UserDict.UserDict class is a subclass of
DictMixin, this allow to simplify UserDict
implementation. The patch is rather conservative since
a lot of methods definition could still be removed from
UserDict.

In the weakref module, the  patch make
WeakValueDictionnary and WeakKeyDictionnary subclasses
of UserDict.DictMixin. It also use nested scopes, the
new generators syntax  for iterator methods and rewrite
WeakKeyDictionnary.__delitem__ . All of this allow to
decrease the 
module size by 50%.

In the shelve module, the patch add a copy() method
which return a dictionary with the keys and values of
the database.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-15 21:35

Message:
Logged In: YES 
user_id=80475

* UserDict.UserDict should not change. As Martin pointed-
out, inheriting from object changes the semantics in a non-
backward compatible way.  Also, the class is efficiently 
implemented in terms an internal dictionary and would be 
slowed down by the nest of calls in Mixin.  Also, I think the 
code in incorrect in defining __iter__, there was a reason it 
was pulled out into a separate subclass -- that was done in 
Py2.2. and is not an easily reversible decision.

*  -0 on the changes to has_key() and __contains__(). 
has_key() was put at a lower level than __contains__ 
because the older dict-style interfaces all define has_key.

* +1 for changing iterkeys() to a full definition (and +1 for 
doing the same for __iter__()).  Sabastien is correct is 
pointing out the advantages for propagating an overridden 
method.

* -1 for altering repr() implementation.  The current 
approach is shorter, cleaner, and faster.

* -1 for adding __nonzero__().  Even dictionaries don't 
implement this method; they let len() do the talking.

* -1 for adding __init__() and copy().  Both need to make 
assumptions about the order and number of parameters 
in the constructor of the class using the mixin.  I think they 
are rarely helpful and are sometime harmful in introducing 
surprising, hard-to-find errors.  People who need an init() 
or copy() can code them more cleanly and directly in the 
extending class.  Also, I don't think the code is correct 
since DictMixin will be a base class, the use of super() is 
not what is wanted here -- *if* you were going to do this, 
try something like self.__class__().  Further, adding these 
methods violates my original intent for this class which 
was to extrapolate four basic mapping methods into a full 
mapping interface.  It was not intended as a stand-alone 
class.  Also, copy() cannot guarantee that it is copying all 
the relevant data for the sub-class and that violates the 
definition of what copy() is supposed to do.  If something 
like this were attempted, it should be its own mixin 
(automatically adding copy support to any class) and it 
should be rather sophisticated about how to perfectly 
replicate itself (not easily done if the underlying data is in a 
file, database, or in a distributed app).

* +0 on changing weakdicts provided it is done minimally 
and carefully with attention to leaving semantics 
unchanged and not slowing performance.  The advantage 
goes beyond consistency, it removes code duplication, 
keeps well thought-out logic in one place, and provides an 
automatic interface update from DictMixin if the dictionary 
interface ever sprouts another method.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-14 16:43

Message:
Logged In: YES 
user_id=21627

This patch breaks backwards compatibility. UserDict is an
oldstyle class on purpose, since changing it to a newstyle
class will certainly break the compatibility in subtle ways
(e.g. by changing what type(userdictinstance) is).

Unless you can bring forward a better rationale than
consistency, this patch will be rejected.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667730&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 02:45:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 18:45:21 -0800
Subject: [Patches] [ python-Patches-668500 ] doctest handles comments incorrectly
Message-ID: <E18Z01x-0005fu-00@sc8-sf-web4.sourceforge.net>

Patches item #668500, was opened at 2003-01-15 09:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668500&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Schmolck (aschmolck)
Assigned to: Tim Peters (tim_one)
Summary: doctest handles comments incorrectly

Initial Comment:
> >    import doctest, test
> >    def aTest():
> >        r""">>> # A comment
> >            ... print 'This is incorrectly ignored
by doctest'
> >            This output here really doesn't matter
either... (but SHOULD)
> >            >>>
> >            """

the patch fixes that and passes the original doctest
tests. (test_doctest and doctest.py itself)


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-01-15 21:45

Message:
Logged In: YES 
user_id=31435

Alexander, you need to check the "Check to Upload and 
Attach a File" box when trying to attach a file.  This is a 
SourceForge annoyance we have no control over.  Please 
try again!

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-15 20:56

Message:
Logged In: YES 
user_id=80475

The file attachment didn't make it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668500&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 02:50:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 18:50:17 -0800
Subject: [Patches] [ python-Patches-667730 ] More DictMixin
Message-ID: <E18Z06j-0004mP-00@sc8-sf-web2.sourceforge.net>

Patches item #667730, was opened at 2003-01-14 08:27
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667730&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sebastien Keim (s_keim)
Assigned to: Nobody/Anonymous (nobody)
Summary: More DictMixin

Initial Comment:
This patch is intended to provide a more consistent
implementation for the various dictionary like objects
of the standard library.

test_userdict has been rewritten, it now use unittest
and define a test-case wich allow to check for
conformity with the dictionary protocol. 

test_shelve and test_weakref have been rewritten to use
the test_userdict test-case.

test_os has been extended: a new test case check for
environ object conformity to the dictionary protocol.

The patch modify the UserDict module:
* The doc says that __contains__ should be one of the
methods to redefine for better efficiency but the
implementation make __contains__ dependent of has_key
definition. The patch reverse methods dependencies.
* Change iterkey = __iter__ to def iterkey(self):
return self.__iter__() to make iterkey able to use
overiden __iter__ methods. 
* I have also a added __init__, copy and  __repr__
methods to DictMixin. 
* The UserDict.UserDict class is a subclass of
DictMixin, this allow to simplify UserDict
implementation. The patch is rather conservative since
a lot of methods definition could still be removed from
UserDict.

In the weakref module, the  patch make
WeakValueDictionnary and WeakKeyDictionnary subclasses
of UserDict.DictMixin. It also use nested scopes, the
new generators syntax  for iterator methods and rewrite
WeakKeyDictionnary.__delitem__ . All of this allow to
decrease the 
module size by 50%.

In the shelve module, the patch add a copy() method
which return a dictionary with the keys and values of
the database.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-15 21:50

Message:
Logged In: YES 
user_id=80475

Also, +1 on consolidating the test cases though it should 
be done after any other changes to the files so we can 
make sure that nothing got broken.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-15 21:35

Message:
Logged In: YES 
user_id=80475

* UserDict.UserDict should not change. As Martin pointed-
out, inheriting from object changes the semantics in a non-
backward compatible way.  Also, the class is efficiently 
implemented in terms an internal dictionary and would be 
slowed down by the nest of calls in Mixin.  Also, I think the 
code in incorrect in defining __iter__, there was a reason it 
was pulled out into a separate subclass -- that was done in 
Py2.2. and is not an easily reversible decision.

*  -0 on the changes to has_key() and __contains__(). 
has_key() was put at a lower level than __contains__ 
because the older dict-style interfaces all define has_key.

* +1 for changing iterkeys() to a full definition (and +1 for 
doing the same for __iter__()).  Sabastien is correct is 
pointing out the advantages for propagating an overridden 
method.

* -1 for altering repr() implementation.  The current 
approach is shorter, cleaner, and faster.

* -1 for adding __nonzero__().  Even dictionaries don't 
implement this method; they let len() do the talking.

* -1 for adding __init__() and copy().  Both need to make 
assumptions about the order and number of parameters 
in the constructor of the class using the mixin.  I think they 
are rarely helpful and are sometime harmful in introducing 
surprising, hard-to-find errors.  People who need an init() 
or copy() can code them more cleanly and directly in the 
extending class.  Also, I don't think the code is correct 
since DictMixin will be a base class, the use of super() is 
not what is wanted here -- *if* you were going to do this, 
try something like self.__class__().  Further, adding these 
methods violates my original intent for this class which 
was to extrapolate four basic mapping methods into a full 
mapping interface.  It was not intended as a stand-alone 
class.  Also, copy() cannot guarantee that it is copying all 
the relevant data for the sub-class and that violates the 
definition of what copy() is supposed to do.  If something 
like this were attempted, it should be its own mixin 
(automatically adding copy support to any class) and it 
should be rather sophisticated about how to perfectly 
replicate itself (not easily done if the underlying data is in a 
file, database, or in a distributed app).

* +0 on changing weakdicts provided it is done minimally 
and carefully with attention to leaving semantics 
unchanged and not slowing performance.  The advantage 
goes beyond consistency, it removes code duplication, 
keeps well thought-out logic in one place, and provides an 
automatic interface update from DictMixin if the dictionary 
interface ever sprouts another method.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-14 16:43

Message:
Logged In: YES 
user_id=21627

This patch breaks backwards compatibility. UserDict is an
oldstyle class on purpose, since changing it to a newstyle
class will certainly break the compatibility in subtle ways
(e.g. by changing what type(userdictinstance) is).

Unless you can bring forward a better rationale than
consistency, this patch will be rejected.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=667730&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 05:24:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 15 Jan 2003 21:24:00 -0800
Subject: [Patches] [ python-Patches-658599 ] Fix for bug 494589
Message-ID: <E18Z2VU-0005OU-00@sc8-sf-web1.sourceforge.net>

Patches item #658599, was opened at 2002-12-26 18:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Mark Hammond (mhammond)
Summary: Fix for bug 494589

Initial Comment:
This is a fix for bug 494589 (os.path.expandvars)
I suggest using the same code in ntpath and posixpath.
(Maybe have a commonpath.py and let both import it?)

Python version 2.2.2
OS: NT4 SP6 (checked on NT and cygwin)

Miki

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2003-01-16 16:24

Message:
Logged In: YES 
user_id=14198

It was late last night - the idea of ripping out all
duplicated code wont work.  A consolidation may be possible,
but I haven't time.  I'm deleting that patch, but still
believe that

from posixpath import expandvars

is reasonable.  Comments?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-16 06:14

Message:
Logged In: YES 
user_id=31435

Sounds like an excellent idea to me, Mark!  The glory is all 
yours, if you're man enough to accept it <wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-15 23:38

Message:
Logged In: YES 
user_id=14198

In fact, why not go the whole-hog, and remove all code in
ntpath.py that is identical to posixpath.py

Example patch attached <wink>

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-15 14:44

Message:
Logged In: YES 
user_id=14198

Is there any reason why:

from posixpath import expandvars

is not a better patch?  From what I can see, posixpath's
version works fine for Windows (windows os.environ is case
insensitive)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-14 04:59

Message:
Logged In: YES 
user_id=31435

Mark, can you make time to look at this?  I can't.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-04 14:31

Message:
Logged In: YES 
user_id=33168

The patch didn't apply for me, so I created a new one and
attached it.  I can't test this.  Maybe Tim is interested.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2002-12-29 18:28

Message:
Logged In: YES 
user_id=358087

This time the checkbox is checked. :-)

Miki

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-27 05:07

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 09:28:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 01:28:17 -0800
Subject: [Patches] [ python-Patches-666484 ] Japanese Unicode Codecs
Message-ID: <E18Z6Jt-0002GF-00@sc8-sf-web3.sourceforge.net>

Patches item #666484, was opened at 2003-01-12 04:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=666484&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: SUZUKI Hisao (suzuki_hisao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Japanese Unicode Codecs

Initial Comment:
This is an implementation of a set of Japanese Unicode
codecs
for Python 2.2 and 2.3.  Three major encodings are
supported:
EUC-JP, Shift_JIS and ISO-2022-JP.

It is in pure Python, of a reasonable size (< 80KB),
and with
an effective means to modify the mapping tables.


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-16 10:28

Message:
Logged In: YES 
user_id=38388

Sorry for not having read the README earlier. 

You do have a point in that it is useful to be able to modify 
encodings in user-specific ways. Of course, this needs to 
be done by creating new codecs and Python files sure
make this process easier.

Now, AFAIK, none of the current Python developers know 
much about Japanese, so we'd need a maintainer for the 
codecs. If you would be able to take over this part, then
I see a good chance of getting the codecs into the Python
core (Tamito's codecs didn't get accepted for the core
distribution because of their size).

Perhaps you could team up with Tamito in this effort ?!


----------------------------------------------------------------------

Comment By: SUZUKI Hisao (suzuki_hisao)
Date: 2003-01-16 01:22

Message:
Logged In: YES 
user_id=495142

Yes, I know KAJIYAMA's work from version 1.0 to
version 1.4.9.  Indeed I had contributed a patch
to JapaneseCodecs-1.2.  Please read the README
file included in the tar-ball for rationale of
ja-codecs.

As for the efficiency, ja-codecs is fairly fast
and small in practice.  In addition, its mapping
possesses a good mathematical property,
encode(decode(c)) == c for every valid character
c, which is pragmatically useful for many
applications.  (The last version (1.4.9) of
KAJIYAMA's codecs has also remedied it on a
particular character: REVERSE SOLIDUS.  It seems
to lack a validation test like that of
ja-codes-0.6/ja/map_jisx206.py, though.)

As you know, KAJIYAMA's codecs set does not also
cover all the encodings used in Japan today.  For
example, it does not support those of Macintosh.
It might be almost impossible to make a perfect
set of codecs in a realistic size.  It would be
best for "standard library" to prepare a few
"standard" (based on public specifications and in
use over various platforms) encodings, which can
be _easily_ modified by users/developers in order
to be adapted to their specific platforms (in the
spirit of "open source" ;-).

So I think it would be mandatory for Japanese
codecs of standard library to be written in Python
cleanly as well as efficiently enough, or at
least, to effectively allow users to modify
character mappings.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-12 13:33

Message:
Logged In: YES 
user_id=38388

Are you aware of the codecs written by Tamito KAJIYAMA ?

   http://www.asahi-net.or.jp/~rd6t-kjym/python/

These are written in C and provide a much improved performance
over Python based ones. They cover the same set of encodings you
have in your packagea dn also include a complete test suite
for the
codecs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=666484&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 10:26:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 02:26:36 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18Z7EK-0004JP-00@sc8-sf-web4.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 21:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
>Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-01-16 11:26

Message:
Logged In: YES 
user_id=11105

Don't know if this is a bug or not (and to be honest, I don't 
care). I just have the habit to report these things when I find 
them.

IMO it's at least inconsitent that all the unsigned format 
codes "HLQ" don't accept negative numbers, but "IL" do.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-15 23:21

Message:
Logged In: YES 
user_id=33168

This didn't raise an exception in 2.1.1 either.  Is this
really a bug or just the behaviour?  Should the fix be to update
doc rather than code?  Don't you need to fix get_ulonglong()
in a similar way?

I'm not necessarily against the patch, perhaps this should
be brought up on python-dev?

If the patch is accepted, you need to make a NEWS entry, and
probably should update libstruct.tex.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-14 21:42

Message:
Logged In: YES 
user_id=11105

This is an upper-case 'i', meaning 'unsigned int'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 11:33:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 03:33:28 -0800
Subject: [Patches] [ python-Patches-662454 ] (Bug 660811: importing x.y.z as m is possible, docs say othe
Message-ID: <E18Z8H2-0004YX-00@sc8-sf-web2.sourceforge.net>

Patches item #662454, was opened at 2003-01-05 04:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662454&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Christopher Blunck (blunck2)
Assigned to: Martin v. Löwis (loewis)
Summary: (Bug 660811: importing x.y.z as m is possible, docs say othe

Initial Comment:
import os.path as o works in: 2.2.x, and 2.1.x. 
It does not work in 1.5.2 because the "as" keyword did
not exist.

Perhaps this is a left-over from docs from the 1.5 era?

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-16 12:33

Message:
Logged In: YES 
user_id=21627

Thanks for the patch, committed as ref6.tex 1.60.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662454&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 15:54:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 07:54:01 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18ZCLB-000342-00@sc8-sf-web3.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 15:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

>Category: Modules
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Thomas Heller (theller)
>Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 10:54

Message:
Logged In: YES 
user_id=33168

I'm convinced it's a bug.  The patch is fine, but a NEWS
item and test should also be added.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-16 05:26

Message:
Logged In: YES 
user_id=11105

Don't know if this is a bug or not (and to be honest, I don't 
care). I just have the habit to report these things when I find 
them.

IMO it's at least inconsitent that all the unsigned format 
codes "HLQ" don't accept negative numbers, but "IL" do.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-15 17:21

Message:
Logged In: YES 
user_id=33168

This didn't raise an exception in 2.1.1 either.  Is this
really a bug or just the behaviour?  Should the fix be to update
doc rather than code?  Don't you need to fix get_ulonglong()
in a similar way?

I'm not necessarily against the patch, perhaps this should
be brought up on python-dev?

If the patch is accepted, you need to make a NEWS entry, and
probably should update libstruct.tex.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-14 15:42

Message:
Logged In: YES 
user_id=11105

This is an upper-case 'i', meaning 'unsigned int'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 15:55:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 07:55:41 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18ZCMn-0003C5-00@sc8-sf-web3.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 15:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
>Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 10:55

Message:
Logged In: YES 
user_id=33168

Oops, I spoke too soon.  test_grammar failed -- max negative int
Not sure if that's a test problem or something else, but it
needs to be addressed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 10:54

Message:
Logged In: YES 
user_id=33168

I'm convinced it's a bug.  The patch is fine, but a NEWS
item and test should also be added.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-16 05:26

Message:
Logged In: YES 
user_id=11105

Don't know if this is a bug or not (and to be honest, I don't 
care). I just have the habit to report these things when I find 
them.

IMO it's at least inconsitent that all the unsigned format 
codes "HLQ" don't accept negative numbers, but "IL" do.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-15 17:21

Message:
Logged In: YES 
user_id=33168

This didn't raise an exception in 2.1.1 either.  Is this
really a bug or just the behaviour?  Should the fix be to update
doc rather than code?  Don't you need to fix get_ulonglong()
in a similar way?

I'm not necessarily against the patch, perhaps this should
be brought up on python-dev?

If the patch is accepted, you need to make a NEWS entry, and
probably should update libstruct.tex.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-14 15:42

Message:
Logged In: YES 
user_id=11105

This is an upper-case 'i', meaning 'unsigned int'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 16:16:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 08:16:44 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18ZChA-0001U3-00@sc8-sf-web2.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 15:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
>Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-01-16 11:16

Message:
Logged In: YES 
user_id=31435

This should definitely be brought up on Python-Dev.  The 
rules for what struct will and won't accept are an historical 
minefield, and if "I" stops accepting negative Python (short) 
ints, I expect lots of code would break.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 10:55

Message:
Logged In: YES 
user_id=33168

Oops, I spoke too soon.  test_grammar failed -- max negative int
Not sure if that's a test problem or something else, but it
needs to be addressed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 10:54

Message:
Logged In: YES 
user_id=33168

I'm convinced it's a bug.  The patch is fine, but a NEWS
item and test should also be added.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-16 05:26

Message:
Logged In: YES 
user_id=11105

Don't know if this is a bug or not (and to be honest, I don't 
care). I just have the habit to report these things when I find 
them.

IMO it's at least inconsitent that all the unsigned format 
codes "HLQ" don't accept negative numbers, but "IL" do.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-15 17:21

Message:
Logged In: YES 
user_id=33168

This didn't raise an exception in 2.1.1 either.  Is this
really a bug or just the behaviour?  Should the fix be to update
doc rather than code?  Don't you need to fix get_ulonglong()
in a similar way?

I'm not necessarily against the patch, perhaps this should
be brought up on python-dev?

If the patch is accepted, you need to make a NEWS entry, and
probably should update libstruct.tex.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-14 15:42

Message:
Logged In: YES 
user_id=11105

This is an upper-case 'i', meaning 'unsigned int'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 16:20:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 08:20:57 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18ZClF-0005sW-00@sc8-sf-web1.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 20:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
>Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-01-16 16:20

Message:
Logged In: YES 
user_id=6656

nnorwitz:

> Oops, I spoke too soon.  test_grammar failed -- max
negative int
> Not sure if that's a test problem or something else, but it
> needs to be addressed.

Nah, that'll be your work on bug #660455.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-16 16:16

Message:
Logged In: YES 
user_id=31435

This should definitely be brought up on Python-Dev.  The 
rules for what struct will and won't accept are an historical 
minefield, and if "I" stops accepting negative Python (short) 
ints, I expect lots of code would break.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 15:55

Message:
Logged In: YES 
user_id=33168

Oops, I spoke too soon.  test_grammar failed -- max negative int
Not sure if that's a test problem or something else, but it
needs to be addressed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 15:54

Message:
Logged In: YES 
user_id=33168

I'm convinced it's a bug.  The patch is fine, but a NEWS
item and test should also be added.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-16 10:26

Message:
Logged In: YES 
user_id=11105

Don't know if this is a bug or not (and to be honest, I don't 
care). I just have the habit to report these things when I find 
them.

IMO it's at least inconsitent that all the unsigned format 
codes "HLQ" don't accept negative numbers, but "IL" do.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-15 22:21

Message:
Logged In: YES 
user_id=33168

This didn't raise an exception in 2.1.1 either.  Is this
really a bug or just the behaviour?  Should the fix be to update
doc rather than code?  Don't you need to fix get_ulonglong()
in a similar way?

I'm not necessarily against the patch, perhaps this should
be brought up on python-dev?

If the patch is accepted, you need to make a NEWS entry, and
probably should update libstruct.tex.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-14 20:42

Message:
Logged In: YES 
user_id=11105

This is an upper-case 'i', meaning 'unsigned int'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 16:53:09 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 08:53:09 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18ZDGP-0005q3-00@sc8-sf-web3.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 15:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
>Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-01-16 11:53

Message:
Logged In: YES 
user_id=31435

It's not really hard to do range-checks portably, it's more that 
the C code didn't, and then people relied on the holes.

Note that since Python exposes no unsigned int type, 
someone who wants to write out what they *think* of as being 
a 32-bit bitmask value on a 32-bit box may very well pass "a 
negative number" to pack() with an "I" format.

What "should be" done here may be affected by the int/long 
unification plans, and so is a good topic for Python-Dev.  I'm -
1 on this patch for 2.3, though -- it will break code.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-16 11:23

Message:
Logged In: YES 
user_id=11105

Neil: test_grammar, as well as all the other tests which 
usually pass on my machine (Win2k) pass again with this 
patch.

Tim: I've just looked into test_struct.py, and it seems that 
most of the integer range tests are carefully skipped. I 
assume this is a difficult field, with all different platforms.

As I said before, I don't insist on the patch, I just wanted to 
be a good citizen reporting and trying to fix this. Now I think I 
should retract the patch and close it as "Wont fix". Not worth 
breaking code.

Does this make sense?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-16 11:20

Message:
Logged In: YES 
user_id=6656

nnorwitz:

> Oops, I spoke too soon.  test_grammar failed -- max
negative int
> Not sure if that's a test problem or something else, but it
> needs to be addressed.

Nah, that'll be your work on bug #660455.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-16 11:16

Message:
Logged In: YES 
user_id=31435

This should definitely be brought up on Python-Dev.  The 
rules for what struct will and won't accept are an historical 
minefield, and if "I" stops accepting negative Python (short) 
ints, I expect lots of code would break.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 10:55

Message:
Logged In: YES 
user_id=33168

Oops, I spoke too soon.  test_grammar failed -- max negative int
Not sure if that's a test problem or something else, but it
needs to be addressed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 10:54

Message:
Logged In: YES 
user_id=33168

I'm convinced it's a bug.  The patch is fine, but a NEWS
item and test should also be added.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-16 05:26

Message:
Logged In: YES 
user_id=11105

Don't know if this is a bug or not (and to be honest, I don't 
care). I just have the habit to report these things when I find 
them.

IMO it's at least inconsitent that all the unsigned format 
codes "HLQ" don't accept negative numbers, but "IL" do.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-15 17:21

Message:
Logged In: YES 
user_id=33168

This didn't raise an exception in 2.1.1 either.  Is this
really a bug or just the behaviour?  Should the fix be to update
doc rather than code?  Don't you need to fix get_ulonglong()
in a similar way?

I'm not necessarily against the patch, perhaps this should
be brought up on python-dev?

If the patch is accepted, you need to make a NEWS entry, and
probably should update libstruct.tex.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-14 15:42

Message:
Logged In: YES 
user_id=11105

This is an upper-case 'i', meaning 'unsigned int'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 17:02:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 09:02:43 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18ZDPf-0004Nu-00@sc8-sf-web2.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 21:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

Category: Modules
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
>Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-16 17:53

Message:
Logged In: YES 
user_id=31435

It's not really hard to do range-checks portably, it's more that 
the C code didn't, and then people relied on the holes.

Note that since Python exposes no unsigned int type, 
someone who wants to write out what they *think* of as being 
a 32-bit bitmask value on a 32-bit box may very well pass "a 
negative number" to pack() with an "I" format.

What "should be" done here may be affected by the int/long 
unification plans, and so is a good topic for Python-Dev.  I'm -
1 on this patch for 2.3, though -- it will break code.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-16 17:23

Message:
Logged In: YES 
user_id=11105

Neil: test_grammar, as well as all the other tests which 
usually pass on my machine (Win2k) pass again with this 
patch.

Tim: I've just looked into test_struct.py, and it seems that 
most of the integer range tests are carefully skipped. I 
assume this is a difficult field, with all different platforms.

As I said before, I don't insist on the patch, I just wanted to 
be a good citizen reporting and trying to fix this. Now I think I 
should retract the patch and close it as "Wont fix". Not worth 
breaking code.

Does this make sense?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-16 17:20

Message:
Logged In: YES 
user_id=6656

nnorwitz:

> Oops, I spoke too soon.  test_grammar failed -- max
negative int
> Not sure if that's a test problem or something else, but it
> needs to be addressed.

Nah, that'll be your work on bug #660455.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-16 17:16

Message:
Logged In: YES 
user_id=31435

This should definitely be brought up on Python-Dev.  The 
rules for what struct will and won't accept are an historical 
minefield, and if "I" stops accepting negative Python (short) 
ints, I expect lots of code would break.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 16:55

Message:
Logged In: YES 
user_id=33168

Oops, I spoke too soon.  test_grammar failed -- max negative int
Not sure if that's a test problem or something else, but it
needs to be addressed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 16:54

Message:
Logged In: YES 
user_id=33168

I'm convinced it's a bug.  The patch is fine, but a NEWS
item and test should also be added.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-16 11:26

Message:
Logged In: YES 
user_id=11105

Don't know if this is a bug or not (and to be honest, I don't 
care). I just have the habit to report these things when I find 
them.

IMO it's at least inconsitent that all the unsigned format 
codes "HLQ" don't accept negative numbers, but "IL" do.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-15 23:21

Message:
Logged In: YES 
user_id=33168

This didn't raise an exception in 2.1.1 either.  Is this
really a bug or just the behaviour?  Should the fix be to update
doc rather than code?  Don't you need to fix get_ulonglong()
in a similar way?

I'm not necessarily against the patch, perhaps this should
be brought up on python-dev?

If the patch is accepted, you need to make a NEWS entry, and
probably should update libstruct.tex.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-14 21:42

Message:
Logged In: YES 
user_id=11105

This is an upper-case 'i', meaning 'unsigned int'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 18:18:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 10:18:11 -0800
Subject: [Patches] [ python-Patches-669198 ] Add cflags to RC compile
Message-ID: <E18ZEah-0003Pp-00@sc8-sf-web1.sourceforge.net>

Patches item #669198, was opened at 2003-01-16 10:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669198&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Dunn (robind)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add cflags to RC compile

Initial Comment:
wxPython's setup.py needs to give the -I flags to the
rc.exe command so the #include in the .rc file can find
the specified file.  This little one line change to
msvccompiler.py adds all the -I and -D flags used for
the C compiler to the RC compiler as well, and solves
wxPython's problem.

BTW, this is the last distutils thing that I have to
workaround in wxPython's setup.py.  With the distutils
in 2.3 I will be able to remove all my other hacks.  If
this patch makes it in the final then they will all be
gone.



----------------------------------------------------------------------

>Comment By: Robin Dunn (robind)
Date: 2003-01-16 10:18

Message:
Logged In: YES 
user_id=53955

attached patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669198&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 18:16:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 10:16:55 -0800
Subject: [Patches] [ python-Patches-669198 ] Add cflags to RC compile
Message-ID: <E18ZEZT-0003Jv-00@sc8-sf-web1.sourceforge.net>

Patches item #669198, was opened at 2003-01-16 10:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669198&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Dunn (robind)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add cflags to RC compile

Initial Comment:
wxPython's setup.py needs to give the -I flags to the
rc.exe command so the #include in the .rc file can find
the specified file.  This little one line change to
msvccompiler.py adds all the -I and -D flags used for
the C compiler to the RC compiler as well, and solves
wxPython's problem.

BTW, this is the last distutils thing that I have to
workaround in wxPython's setup.py.  With the distutils
in 2.3 I will be able to remove all my other hacks.  If
this patch makes it in the final then they will all be
gone.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669198&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 16:23:19 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 08:23:19 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18ZCnX-0004ff-00@sc8-sf-web3.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 21:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
>Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-01-16 17:23

Message:
Logged In: YES 
user_id=11105

Neil: test_grammar, as well as all the other tests which 
usually pass on my machine (Win2k) pass again with this 
patch.

Tim: I've just looked into test_struct.py, and it seems that 
most of the integer range tests are carefully skipped. I 
assume this is a difficult field, with all different platforms.

As I said before, I don't insist on the patch, I just wanted to 
be a good citizen reporting and trying to fix this. Now I think I 
should retract the patch and close it as "Wont fix". Not worth 
breaking code.

Does this make sense?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-16 17:20

Message:
Logged In: YES 
user_id=6656

nnorwitz:

> Oops, I spoke too soon.  test_grammar failed -- max
negative int
> Not sure if that's a test problem or something else, but it
> needs to be addressed.

Nah, that'll be your work on bug #660455.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-16 17:16

Message:
Logged In: YES 
user_id=31435

This should definitely be brought up on Python-Dev.  The 
rules for what struct will and won't accept are an historical 
minefield, and if "I" stops accepting negative Python (short) 
ints, I expect lots of code would break.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 16:55

Message:
Logged In: YES 
user_id=33168

Oops, I spoke too soon.  test_grammar failed -- max negative int
Not sure if that's a test problem or something else, but it
needs to be addressed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 16:54

Message:
Logged In: YES 
user_id=33168

I'm convinced it's a bug.  The patch is fine, but a NEWS
item and test should also be added.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-16 11:26

Message:
Logged In: YES 
user_id=11105

Don't know if this is a bug or not (and to be honest, I don't 
care). I just have the habit to report these things when I find 
them.

IMO it's at least inconsitent that all the unsigned format 
codes "HLQ" don't accept negative numbers, but "IL" do.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-15 23:21

Message:
Logged In: YES 
user_id=33168

This didn't raise an exception in 2.1.1 either.  Is this
really a bug or just the behaviour?  Should the fix be to update
doc rather than code?  Don't you need to fix get_ulonglong()
in a similar way?

I'm not necessarily against the patch, perhaps this should
be brought up on python-dev?

If the patch is accepted, you need to make a NEWS entry, and
probably should update libstruct.tex.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-14 21:42

Message:
Logged In: YES 
user_id=11105

This is an upper-case 'i', meaning 'unsigned int'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 18:37:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 10:37:00 -0800
Subject: [Patches] [ python-Patches-668124 ] struct.pack("I", -3) doesn't raise an exception
Message-ID: <E18ZEsu-0004ac-00@sc8-sf-web1.sourceforge.net>

Patches item #668124, was opened at 2003-01-14 15:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470

Category: Modules
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
>Summary: struct.pack("I", -3) doesn't raise an exception

Initial Comment:
Each time I try to 'steal' code from Python, I seem to 
find a bug ;-)

This bug is also in 2.2.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 13:36

Message:
Logged In: YES 
user_id=33168

Michael, thanks.  You are correct.  I will have to look at
that more.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-16 11:53

Message:
Logged In: YES 
user_id=31435

It's not really hard to do range-checks portably, it's more that 
the C code didn't, and then people relied on the holes.

Note that since Python exposes no unsigned int type, 
someone who wants to write out what they *think* of as being 
a 32-bit bitmask value on a 32-bit box may very well pass "a 
negative number" to pack() with an "I" format.

What "should be" done here may be affected by the int/long 
unification plans, and so is a good topic for Python-Dev.  I'm -
1 on this patch for 2.3, though -- it will break code.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-16 11:23

Message:
Logged In: YES 
user_id=11105

Neil: test_grammar, as well as all the other tests which 
usually pass on my machine (Win2k) pass again with this 
patch.

Tim: I've just looked into test_struct.py, and it seems that 
most of the integer range tests are carefully skipped. I 
assume this is a difficult field, with all different platforms.

As I said before, I don't insist on the patch, I just wanted to 
be a good citizen reporting and trying to fix this. Now I think I 
should retract the patch and close it as "Wont fix". Not worth 
breaking code.

Does this make sense?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-16 11:20

Message:
Logged In: YES 
user_id=6656

nnorwitz:

> Oops, I spoke too soon.  test_grammar failed -- max
negative int
> Not sure if that's a test problem or something else, but it
> needs to be addressed.

Nah, that'll be your work on bug #660455.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-16 11:16

Message:
Logged In: YES 
user_id=31435

This should definitely be brought up on Python-Dev.  The 
rules for what struct will and won't accept are an historical 
minefield, and if "I" stops accepting negative Python (short) 
ints, I expect lots of code would break.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 10:55

Message:
Logged In: YES 
user_id=33168

Oops, I spoke too soon.  test_grammar failed -- max negative int
Not sure if that's a test problem or something else, but it
needs to be addressed.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 10:54

Message:
Logged In: YES 
user_id=33168

I'm convinced it's a bug.  The patch is fine, but a NEWS
item and test should also be added.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-16 05:26

Message:
Logged In: YES 
user_id=11105

Don't know if this is a bug or not (and to be honest, I don't 
care). I just have the habit to report these things when I find 
them.

IMO it's at least inconsitent that all the unsigned format 
codes "HLQ" don't accept negative numbers, but "IL" do.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-15 17:21

Message:
Logged In: YES 
user_id=33168

This didn't raise an exception in 2.1.1 either.  Is this
really a bug or just the behaviour?  Should the fix be to update
doc rather than code?  Don't you need to fix get_ulonglong()
in a similar way?

I'm not necessarily against the patch, perhaps this should
be brought up on python-dev?

If the patch is accepted, you need to make a NEWS entry, and
probably should update libstruct.tex.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-14 15:42

Message:
Logged In: YES 
user_id=11105

This is an upper-case 'i', meaning 'unsigned int'.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668124&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 20:47:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 12:47:38 -0800
Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest
Message-ID: <E18ZGvK-0007fX-00@sc8-sf-web3.sourceforge.net>

Patches item #662807, was opened at 2003-01-05 21:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Port tests to unittest

Initial Comment:
This patch ports the three tests test_pow.py, 
test_charmapcodec.py and test_userdict.py to unittest.

----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-16 21:47

Message:
Logged In: YES 
user_id=89016

test_unicode is ported and enhanced (coverage goes from
80.81% to 85.05%)

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-10 18:17

Message:
Logged In: YES 
user_id=89016

> In general, don't do tests that hardwire implementation 
details

So should we remove
self.assertEquals(reduce(42, "1"), "1")
self.assertEquals(reduce(42, "", "1"), "1")
from test_filter?

BTW, you should look at test_builtin first, as the others
are still simply ports to PyUnit.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-10 18:03

Message:
Logged In: YES 
user_id=80475

Good to hear the news on increasing the coverage.

In general, don't do tests that hardwire implementation 
details.  Test it if it is a documented variable,  exposed 
through __all__, is a key constact (like the magic numbers 
in random.py), or a variable that a module user is likely to 
be relying upon.  Otherwise, no -- it should be possible to 
improve an implementation without crashing the suite.

I'll try to review a few of these over the next few days.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-10 17:53

Message:
Logged In: YES 
user_id=89016

test_builtin.py is now updated to test more error
situations. This increases the coverage of bltinmodule.c
from 75.13% to 92.20%, and it actually revealed one or two
potential bugs:
http://www.python.org/sf/665761 and
http://www.python.org/sf/665835

I'm not 100% sure that test_intern() and test_execfile() do
the right thing.

I'm not sure, whether the test script should check for
undocumented implementation artefacts, like:

a = 1
self.assert_(min(a, 1L) is a)

but in this way at least we get notified if something is
changed unintentionally.


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-08 20:05

Message:
Logged In: YES 
user_id=89016

test_b1 and test_b2 are combined into test_builtin now

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 15:03

Message:
Logged In: YES 
user_id=6380

Two random suggestions:

- a blank line before each method, even trivial ones, even
the first one

- use assertEqual, not assertEquals

BTW, I see you've picked up on the convention that unit test
methods should not have doc strings. Good! (But they may
have comments.)

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-07 17:37

Message:
Logged In: YES 
user_id=89016

test_b1.py has been ported too.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-05 21:56

Message:
Logged In: YES 
user_id=89016

The patch is hard to read, so I'll upload all three test scripts.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470


From noreply@sourceforge.net  Thu Jan 16 21:42:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 13:42:08 -0800
Subject: [Patches] [ python-Patches-665458 ] Crash in binascii_a2b_uu on corrupt data
Message-ID: <E18ZHm4-00020l-00@sc8-sf-web2.sourceforge.net>

Patches item #665458, was opened at 2003-01-09 21:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665458&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Scharf (scharf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash in binascii_a2b_uu on corrupt data

Initial Comment:
When I unpacked 50 gigabytes of randomly downloaded 
usenet binary news posts python crashed (randomly) on 
windows. After long tracking (I did'nt have a debug 
version) I found the problem in binascii_a2b_uu:

When reading the input data, the boundaries of the input 
sting are not checked. With corrupted uuencoded data 
(the first bite gives the length of the encoded string), the 
function reads out of bounds of the input string. That is 
not a problem (in most cases) but sometimes (it 
happened typicallyafter 20-30 gibagytes of parsed data) 
the allocated string might be at the end of a 
memory 'segment' and there is no string after the 
allocated string. And that causes a crash.

I have attached a patch to solve the problem. (Python 
2.2.2)

Michael

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-16 16:42

Message:
Logged In: YES 
user_id=33168

I agree there is a problem, although I'm concerned about
changing the behaviour.  Currently, if the data is short it
is, it is filled with null characters.  With this patch an
exception is raised.  Ideally, the patch is correct, but my
concern is that many people rely on the output being
null-filled.

I believe the following change around line 207, keeps the
behaviour and would avoid the crash:

-               this_ch = *ascii_data;
+               this_ch = (ascii_len > 0) ? *ascii_data : 0;


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=665458&group_id=5470


From noreply@sourceforge.net  Fri Jan 17 01:24:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 17:24:28 -0800
Subject: [Patches] [ python-Patches-658599 ] Fix for bug 494589
Message-ID: <E18ZLFE-0001fB-00@sc8-sf-web4.sourceforge.net>

Patches item #658599, was opened at 2002-12-26 02:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Mark Hammond (mhammond)
Summary: Fix for bug 494589

Initial Comment:
This is a fix for bug 494589 (os.path.expandvars)
I suggest using the same code in ntpath and posixpath.
(Maybe have a commonpath.py and let both import it?)

Python version 2.2.2
OS: NT4 SP6 (checked on NT and cygwin)

Miki

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-01-16 20:24

Message:
Logged In: YES 
user_id=31435

Did you look at bug 494589?  As I noted there, there are 
semantic diffferences between the ntpath and posixpath 
versions of .expandvars() (like ntpath mapping $$ to $, 
and not expanding within single quotes).

I personally have no use for the differences, but can't say 
whether anyone else does.  The author of the ntpath version 
took time to write comments about its pecularities, so they 
weren't accidents at the time.  Incompatible changes are 
usually PEP material.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-16 00:24

Message:
Logged In: YES 
user_id=14198

It was late last night - the idea of ripping out all
duplicated code wont work.  A consolidation may be possible,
but I haven't time.  I'm deleting that patch, but still
believe that

from posixpath import expandvars

is reasonable.  Comments?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-15 14:14

Message:
Logged In: YES 
user_id=31435

Sounds like an excellent idea to me, Mark!  The glory is all 
yours, if you're man enough to accept it <wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-15 07:38

Message:
Logged In: YES 
user_id=14198

In fact, why not go the whole-hog, and remove all code in
ntpath.py that is identical to posixpath.py

Example patch attached <wink>

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-14 22:44

Message:
Logged In: YES 
user_id=14198

Is there any reason why:

from posixpath import expandvars

is not a better patch?  From what I can see, posixpath's
version works fine for Windows (windows os.environ is case
insensitive)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-13 12:59

Message:
Logged In: YES 
user_id=31435

Mark, can you make time to look at this?  I can't.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-03 22:31

Message:
Logged In: YES 
user_id=33168

The patch didn't apply for me, so I created a new one and
attached it.  I can't test this.  Maybe Tim is interested.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2002-12-29 02:28

Message:
Logged In: YES 
user_id=358087

This time the checkbox is checked. :-)

Miki

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-26 13:07

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470


From noreply@sourceforge.net  Fri Jan 17 04:02:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 16 Jan 2003 20:02:36 -0800
Subject: [Patches] [ python-Patches-669553 ] fix memory (ref) leaks
Message-ID: <E18ZNiG-0006Cf-00@sc8-sf-web4.sourceforge.net>

Patches item #669553, was opened at 2003-01-16 23:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669553&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix memory (ref) leaks

Initial Comment:
Sorry, I'm lazy and this is a single patch to 2 files
to fix reference leaks.  

The int patch can be demonstrated by doing:

  abs(-2147483648)

The second happens when:

  import pyexpat
  p = pyexpat.ParserCreate()
  p.__members__


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669553&group_id=5470


From noreply@sourceforge.net  Fri Jan 17 09:25:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 17 Jan 2003 01:25:34 -0800
Subject: [Patches] [ python-Patches-669645 ] wininst.exe missing in Windows installer
Message-ID: <E18ZSko-0007Tb-00@sc8-sf-web2.sourceforge.net>

Patches item #669645, was opened at 2003-01-17 10:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669645&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Thomas Heller (theller)
Assigned to: Tim Peters (tim_one)
Summary: wininst.exe missing in Windows installer

Initial Comment:
The wininst.exe file is missing in the Windows binary 
distribution. This file must be in the 
Lib/distutils/command directory, and is needed by the 
bdist_wininst command. Previously (Python 2.2) the 
bytes of this file were literally contained as a base64 
encoded string in the module itself.

I attached a patch for the WISE script which should 
work, but it is untested. You should probably also delete 
all but the last chunk from the patch, these seem to be 
specific for my machine, and the WISE version I have.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669645&group_id=5470


From noreply@sourceforge.net  Fri Jan 17 09:26:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 17 Jan 2003 01:26:51 -0800
Subject: [Patches] [ python-Patches-669645 ] wininst.exe missing in Windows installer
Message-ID: <E18ZSm3-0007MW-00@sc8-sf-web3.sourceforge.net>

Patches item #669645, was opened at 2003-01-17 10:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669645&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Thomas Heller (theller)
Assigned to: Tim Peters (tim_one)
Summary: wininst.exe missing in Windows installer

Initial Comment:
The wininst.exe file is missing in the Windows binary 
distribution. This file must be in the 
Lib/distutils/command directory, and is needed by the 
bdist_wininst command. Previously (Python 2.2) the 
bytes of this file were literally contained as a base64 
encoded string in the module itself.

I attached a patch for the WISE script which should 
work, but it is untested. You should probably also delete 
all but the last chunk from the patch, these seem to be 
specific for my machine, and the WISE version I have.



----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-01-17 10:26

Message:
Logged In: YES 
user_id=11105

Upload patch, second try.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669645&group_id=5470


From noreply@sourceforge.net  Fri Jan 17 10:44:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 17 Jan 2003 02:44:36 -0800
Subject: [Patches] [ python-Patches-669553 ] fix memory (ref) leaks
Message-ID: <E18ZTzI-0002Lv-00@sc8-sf-web4.sourceforge.net>

Patches item #669553, was opened at 2003-01-17 04:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669553&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix memory (ref) leaks

Initial Comment:
Sorry, I'm lazy and this is a single patch to 2 files
to fix reference leaks.  

The int patch can be demonstrated by doing:

  abs(-2147483648)

The second happens when:

  import pyexpat
  p = pyexpat.ParserCreate()
  p.__members__


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-01-17 10:44

Message:
Logged In: YES 
user_id=6656

Looks fine to me.

I haven't tested it, but I assume it compiles and the tests
pass.  I can't see how you could write a test for this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669553&group_id=5470


From noreply@sourceforge.net  Fri Jan 17 11:15:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 17 Jan 2003 03:15:14 -0800
Subject: [Patches] [ python-Patches-669683 ] HTMLParser -- allow "," in attributes
Message-ID: <E18ZUSw-0003cT-00@sc8-sf-web4.sourceforge.net>

Patches item #669683, was opened at 2003-01-17 11:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTMLParser -- allow "," in attributes

Initial Comment:
An HTML document in the wild had the tag:

<font size="-1" color=rgb(175,18,3)>

and HTMLParser was choking on the "," after the 
"175".  By adding "," to the list of allowed characters 
in attribute values, HTMLParser accepts the document.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470


From noreply@sourceforge.net  Fri Jan 17 11:15:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 17 Jan 2003 03:15:47 -0800
Subject: [Patches] [ python-Patches-669684 ] HTMLParser -- allow "," in attributes
Message-ID: <E18ZUTT-0007eq-00@sc8-sf-web1.sourceforge.net>

Patches item #669684, was opened at 2003-01-17 11:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669684&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTMLParser -- allow "," in attributes

Initial Comment:
An HTML document in the wild had the tag:

<font size="-1" color=rgb(175,18,3)>

and HTMLParser was choking on the "," after the 
"175".  By adding "," to the list of allowed characters 
in attribute values, HTMLParser accepts the document.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669684&group_id=5470


From noreply@sourceforge.net  Fri Jan 17 14:17:13 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 17 Jan 2003 06:17:13 -0800
Subject: [Patches] [ python-Patches-669684 ] HTMLParser -- allow "," in attributes
Message-ID: <E18ZXJ3-0006et-00@sc8-sf-web1.sourceforge.net>

Patches item #669684, was opened at 2003-01-17 06:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669684&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
>Summary: HTMLParser -- allow "," in attributes

Initial Comment:
An HTML document in the wild had the tag:

<font size="-1" color=rgb(175,18,3)>

and HTMLParser was choking on the "," after the 
"175".  By adding "," to the list of allowed characters 
in attribute values, HTMLParser accepts the document.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-17 09:17

Message:
Logged In: YES 
user_id=33168

Dup of 669683.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669684&group_id=5470


From noreply@sourceforge.net  Fri Jan 17 14:17:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 17 Jan 2003 06:17:50 -0800
Subject: [Patches] [ python-Patches-669683 ] HTMLParser -- allow "," in attributes
Message-ID: <E18ZXJe-0002J1-00@sc8-sf-web2.sourceforge.net>

Patches item #669683, was opened at 2003-01-17 06:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
>Summary: HTMLParser -- allow "," in attributes

Initial Comment:
An HTML document in the wild had the tag:

<font size="-1" color=rgb(175,18,3)>

and HTMLParser was choking on the "," after the 
"175".  By adding "," to the list of allowed characters 
in attribute values, HTMLParser accepts the document.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-17 09:17

Message:
Logged In: YES 
user_id=33168

Was this supposed to be a patch or a bug report?  There is
no patch attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470


From noreply@sourceforge.net  Fri Jan 17 18:46:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 17 Jan 2003 10:46:33 -0800
Subject: [Patches] [ python-Patches-669683 ] HTMLParser -- allow "," in attributes
Message-ID: <E18ZbVh-0007JR-00@sc8-sf-web4.sourceforge.net>

Patches item #669683, was opened at 2003-01-17 11:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
>Summary: HTMLParser -- allow "," in attributes

Initial Comment:
An HTML document in the wild had the tag:

<font size="-1" color=rgb(175,18,3)>

and HTMLParser was choking on the "," after the 
"175".  By adding "," to the list of allowed characters 
in attribute values, HTMLParser accepts the document.


----------------------------------------------------------------------

>Comment By: j paulson (fantoozler)
Date: 2003-01-17 18:46

Message:
Logged In: YES 
user_id=690612

I'll attach the patch file again.  

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-17 14:17

Message:
Logged In: YES 
user_id=33168

Was this supposed to be a patch or a bug report?  There is
no patch attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470


From noreply@sourceforge.net  Fri Jan 17 21:54:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 17 Jan 2003 13:54:07 -0800
Subject: [Patches] [ python-Patches-669645 ] wininst.exe missing in Windows installer
Message-ID: <E18ZeRD-0006KK-00@sc8-sf-web4.sourceforge.net>

Patches item #669645, was opened at 2003-01-17 04:25
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669645&group_id=5470

>Category: Windows
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Thomas Heller (theller)
Assigned to: Tim Peters (tim_one)
Summary: wininst.exe missing in Windows installer

Initial Comment:
The wininst.exe file is missing in the Windows binary 
distribution. This file must be in the 
Lib/distutils/command directory, and is needed by the 
bdist_wininst command. Previously (Python 2.2) the 
bytes of this file were literally contained as a base64 
encoded string in the module itself.

I attached a patch for the WISE script which should 
work, but it is untested. You should probably also delete 
all but the last chunk from the patch, these seem to be 
specific for my machine, and the WISE version I have.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-01-17 16:54

Message:
Logged In: YES 
user_id=31435

Thanks!  Done.  There's no need for a patch here, just tell me 
the name of the file, and where you want it installed.

It would be good if *something* in the std test suite checked 
for the existence of necessary files.  I run all the tests from a 
fresh installation before releasing an installer, so the only way 
a file can "turn up missing" in a release is if nothing in the 
test suite cares if it's missing.

PCbuild/python20.wse; new revision: 1.116

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-01-17 04:26

Message:
Logged In: YES 
user_id=11105

Upload patch, second try.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669645&group_id=5470


From noreply@sourceforge.net  Fri Jan 17 22:03:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 17 Jan 2003 14:03:21 -0800
Subject: [Patches] [ python-Patches-670012 ] Compatibility changes for _strptime.py
Message-ID: <E18Zea9-0006hs-00@sc8-sf-web4.sourceforge.net>

Patches item #670012, was opened at 2003-01-17 14:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670012&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compatibility changes for _strptime.py

Initial Comment:
This patch has a few compatibility changes so as to be a better drop-in replacement for the C version.  First, the 'y' directive now handles [00, 68] as a suffix for the 21st century while [69, 99] is treated as the suffix for the 20th century (this is for Open Group compatibility).  strptime now returns default values that make it a valid date (this is in response to Kevin Jacobs' discovery that default values of -1 might thow someone off if they use time.mktime(); thread on this can be found at http://mail.python.org/pipermail/python-dev/2003-January/031983.html).  Lastly, the ability to pass in a regex object to use instead of a format string (and the inverse ability to have strptime return a regex object) has been removed.  This is in preparation for a future patch that will add some caching internally to get a speed boost.

test_strptime.py has some tests added and removed.  Also did a minute amount of nit-picky changes.  Some of the changes should have gone in when _strptime.py hit 1.9 in CVS, but I forgot to include them in the patch; sorry about that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670012&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 03:57:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 17 Jan 2003 19:57:35 -0800
Subject: [Patches] [ python-Patches-670012 ] Compatibility changes for _strptime.py
Message-ID: <E18Zk6x-0007xL-00@sc8-sf-web3.sourceforge.net>

Patches item #670012, was opened at 2003-01-17 17:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670012&group_id=5470

Category: Library (Lib)
>Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Brett Cannon (bcannon)
>Assigned to: Tim Peters (tim_one)
Summary: Compatibility changes for _strptime.py

Initial Comment:
This patch has a few compatibility changes so as to be a better drop-in replacement for the C version.  First, the 'y' directive now handles [00, 68] as a suffix for the 21st century while [69, 99] is treated as the suffix for the 20th century (this is for Open Group compatibility).  strptime now returns default values that make it a valid date (this is in response to Kevin Jacobs' discovery that default values of -1 might thow someone off if they use time.mktime(); thread on this can be found at http://mail.python.org/pipermail/python-dev/2003-January/031983.html).  Lastly, the ability to pass in a regex object to use instead of a format string (and the inverse ability to have strptime return a regex object) has been removed.  This is in preparation for a future patch that will add some caching internally to get a speed boost.

test_strptime.py has some tests added and removed.  Also did a minute amount of nit-picky changes.  Some of the changes should have gone in when _strptime.py hit 1.9 in CVS, but I forgot to include them in the patch; sorry about that.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-01-17 22:57

Message:
Logged In: YES 
user_id=31435

Thanks, Brett!  Checked in:

Lib/_strptime.py; new revision: 1.10
Lib/test/test_strptime.py; new revision: 1.9

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670012&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 07:45:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 17 Jan 2003 23:45:45 -0800
Subject: [Patches] [ python-Patches-670194 ] Performance enhancement for _strptime.py
Message-ID: <E18Znfl-0004ic-00@sc8-sf-web3.sourceforge.net>

Patches item #670194, was opened at 2003-01-17 23:45
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670194&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Performance enhancement for _strptime.py

Initial Comment:
Using a suggestion from Tim Peters (see http://mail.python.org/pipermail/python-dev/2003-January/032177.html for the e-mail where Tim makes his suggestion), I have added some code to _strptime.py to enhance its performance.  Specifically, I now cache a TimeRE instance and a dict containing compiled regex objects.  The TimeRE instance prevents rediscovery of locale info when the user does not change the language.  The regex object cache prevents the need to recompile regex objects when the same format string is used again and again.  Both are cleared when the language is changed.

I moved the language discovery code to a module-level function so as to make checking the current language easier.

I also removed the one use of the string module I had (has it been decided how something like string.whitespace is going to be replaced, or is that not a concern?).

I didn't bother writing any tests for this since the code changes are so simple and any breakage would have been discovered by the current tests.  But if there is a desire for tests I will do them.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670194&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 08:58:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 00:58:34 -0800
Subject: [Patches] [ python-Patches-666484 ] Japanese Unicode Codecs
Message-ID: <E18ZooE-0002dF-00@sc8-sf-web1.sourceforge.net>

Patches item #666484, was opened at 2003-01-12 12:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=666484&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: SUZUKI Hisao (suzuki_hisao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Japanese Unicode Codecs

Initial Comment:
This is an implementation of a set of Japanese Unicode
codecs
for Python 2.2 and 2.3.  Three major encodings are
supported:
EUC-JP, Shift_JIS and ISO-2022-JP.

It is in pure Python, of a reasonable size (< 80KB),
and with
an effective means to modify the mapping tables.


----------------------------------------------------------------------

>Comment By: SUZUKI Hisao (suzuki_hisao)
Date: 2003-01-18 17:58

Message:
Logged In: YES 
user_id=495142

It will be very nice if Japanese codecs are got
into the core.  Nowadays even Perl 5.8 has them.

I am very willing to help you and Tamito in codec
maintenance.  I am sorry, but I am so occupied
with my work that I am afraid it might be
difficult to take time off to do it everyday.
Perhaps I will be able to make responses not
daily but weekly. 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-16 18:28

Message:
Logged In: YES 
user_id=38388

Sorry for not having read the README earlier. 

You do have a point in that it is useful to be able to modify 
encodings in user-specific ways. Of course, this needs to 
be done by creating new codecs and Python files sure
make this process easier.

Now, AFAIK, none of the current Python developers know 
much about Japanese, so we'd need a maintainer for the 
codecs. If you would be able to take over this part, then
I see a good chance of getting the codecs into the Python
core (Tamito's codecs didn't get accepted for the core
distribution because of their size).

Perhaps you could team up with Tamito in this effort ?!


----------------------------------------------------------------------

Comment By: SUZUKI Hisao (suzuki_hisao)
Date: 2003-01-16 09:22

Message:
Logged In: YES 
user_id=495142

Yes, I know KAJIYAMA's work from version 1.0 to
version 1.4.9.  Indeed I had contributed a patch
to JapaneseCodecs-1.2.  Please read the README
file included in the tar-ball for rationale of
ja-codecs.

As for the efficiency, ja-codecs is fairly fast
and small in practice.  In addition, its mapping
possesses a good mathematical property,
encode(decode(c)) == c for every valid character
c, which is pragmatically useful for many
applications.  (The last version (1.4.9) of
KAJIYAMA's codecs has also remedied it on a
particular character: REVERSE SOLIDUS.  It seems
to lack a validation test like that of
ja-codes-0.6/ja/map_jisx206.py, though.)

As you know, KAJIYAMA's codecs set does not also
cover all the encodings used in Japan today.  For
example, it does not support those of Macintosh.
It might be almost impossible to make a perfect
set of codecs in a realistic size.  It would be
best for "standard library" to prepare a few
"standard" (based on public specifications and in
use over various platforms) encodings, which can
be _easily_ modified by users/developers in order
to be adapted to their specific platforms (in the
spirit of "open source" ;-).

So I think it would be mandatory for Japanese
codecs of standard library to be written in Python
cleanly as well as efficiently enough, or at
least, to effectively allow users to modify
character mappings.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-12 21:33

Message:
Logged In: YES 
user_id=38388

Are you aware of the codecs written by Tamito KAJIYAMA ?

   http://www.asahi-net.or.jp/~rd6t-kjym/python/

These are written in C and provide a much improved performance
over Python based ones. They cover the same set of encodings you
have in your packagea dn also include a complete test suite
for the
codecs.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=666484&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 11:44:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 03:44:57 -0800
Subject: [Patches] [ python-Patches-670229 ] doc improvement for cStringIO.h
Message-ID: <E18ZrPF-0002Fl-00@sc8-sf-web2.sourceforge.net>

Patches item #670229, was opened at 2003-01-18 12:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670229&group_id=5470

Category: Core (C code)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Gernot Hillier (yoda_gh)
Assigned to: Nobody/Anonymous (nobody)
Summary: doc improvement for cStringIO.h

Initial Comment:
I had some troubles in understanding the doc given in   
Include/cStringIO.h for the C API. So I looked into the source code   
and tried to improve it.   
   
Here's the result ;-)   
  
Made against 2.2.1, but checked it also applies against 2.2.2 
codebase. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670229&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 16:52:56 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 08:52:56 -0800
Subject: [Patches] [ python-Patches-670229 ] doc improvement for cStringIO.h
Message-ID: <E18ZwDI-00050E-00@sc8-sf-web4.sourceforge.net>

Patches item #670229, was opened at 2003-01-18 06:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670229&group_id=5470

Category: Core (C code)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Gernot Hillier (yoda_gh)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: doc improvement for cStringIO.h

Initial Comment:
I had some troubles in understanding the doc given in   
Include/cStringIO.h for the C API. So I looked into the source code   
and tried to improve it.   
   
Here's the result ;-)   
  
Made against 2.2.1, but checked it also applies against 2.2.2 
codebase. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670229&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 18:52:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 10:52:11 -0800
Subject: [Patches] [ python-Patches-669553 ] fix memory (ref) leaks
Message-ID: <E18Zy4h-0007eZ-00@sc8-sf-web2.sourceforge.net>

Patches item #669553, was opened at 2003-01-16 23:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669553&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: fix memory (ref) leaks

Initial Comment:
Sorry, I'm lazy and this is a single patch to 2 files
to fix reference leaks.  

The int patch can be demonstrated by doing:

  abs(-2147483648)

The second happens when:

  import pyexpat
  p = pyexpat.ParserCreate()
  p.__members__


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-17 05:44

Message:
Logged In: YES 
user_id=6656

Looks fine to me.

I haven't tested it, but I assume it compiles and the tests
pass.  I can't see how you could write a test for this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669553&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 19:07:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 11:07:29 -0800
Subject: [Patches] [ python-Patches-670367 ] Micro-optimizations for ceval.c
Message-ID: <E18ZyJV-00082z-00@sc8-sf-web2.sourceforge.net>

Patches item #670367, was opened at 2003-01-18 14:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Micro-optimizations for ceval.c

Initial Comment:
Make the code slightly shorter, faster, and easier to 
read.

* Eliminate unused DUP_TOPX code for x==1.  
compile.c always generates DUP_TOP instead.

* Since only two cases remain for DUP_TOPX, replace 
the switch-case with if-elseif.

* The in-lined integer compare does a CheckExact on 
both arguments.  Since the second is a little more 
likely to fail, test it first.

* The switch-case for IS/IS_NOT and IN/NOT_IN can 
separate the regular and inverted cases with no 
additional work.  For all four paths, saves a test and 
jump.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 19:32:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 11:32:45 -0800
Subject: [Patches] [ python-Patches-670390 ] Patched test harness for logging
Message-ID: <E18Zyhx-00005W-00@sc8-sf-web2.sourceforge.net>

Patches item #670390, was opened at 2003-01-18 19:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670390&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Vinay Sajip (vsajip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patched test harness for logging

Initial Comment:
I've attached test_logging.zip which contains a new 
version of test_logging.py as well as a new version of 
the output file (test_logging).

This moves the closing of a stream till after all the 
threads have completed.

Tested under ActivePython 2.1.1 build 212 under WinXP 
Home, the script now runs correctly both when run from 
the command line and when run under regrtest.

The script uses threads and so imports threading at the 
top. The script was causing a hang *only* when run via 
regrtest or the Python command prompt if run using 
import; I tracked the problem down to the 
ThreadingMixin's process_request method. When I 
copied this into the body of my derived class, it still 
failed; but commenting out the line "import threading" 
solved the problem, at least under WinXP 
Home/ActivePython 2.1.1 build 212. Can anyone shed 
any light on this?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670390&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 20:14:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 12:14:02 -0800
Subject: [Patches] [ python-Patches-670423 ] Add missing identity tests to operator.c
Message-ID: <E18ZzLu-0003im-00@sc8-sf-web4.sourceforge.net>

Patches item #670423, was opened at 2003-01-18 15:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670423&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add missing identity tests to operator.c

Initial Comment:
Define operator.is_ and operator.is_not.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670423&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 22:47:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 14:47:47 -0800
Subject: [Patches] [ python-Patches-670423 ] Add missing identity tests to operator.c
Message-ID: <E18a1kh-00084S-00@sc8-sf-web3.sourceforge.net>

Patches item #670423, was opened at 2003-01-18 21:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670423&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Add missing identity tests to operator.c

Initial Comment:
Define operator.is_ and operator.is_not.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-18 23:47

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply it. Also add an entry to
Misc/NEWS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670423&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 22:52:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 14:52:33 -0800
Subject: [Patches] [ python-Patches-670367 ] Micro-optimizations for ceval.c
Message-ID: <E18a1pJ-000663-00@sc8-sf-web2.sourceforge.net>

Patches item #670367, was opened at 2003-01-18 20:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Micro-optimizations for ceval.c

Initial Comment:
Make the code slightly shorter, faster, and easier to 
read.

* Eliminate unused DUP_TOPX code for x==1.  
compile.c always generates DUP_TOP instead.

* Since only two cases remain for DUP_TOPX, replace 
the switch-case with if-elseif.

* The in-lined integer compare does a CheckExact on 
both arguments.  Since the second is a little more 
likely to fail, test it first.

* The switch-case for IS/IS_NOT and IN/NOT_IN can 
separate the regular and inverted cases with no 
additional work.  For all four paths, saves a test and 
jump.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-18 23:52

Message:
Logged In: YES 
user_id=21627

What kind of speed-up have you observed for what test case?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 22:43:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 14:43:44 -0800
Subject: [Patches] [ python-Patches-670390 ] Patched test harness for logging
Message-ID: <E18a1gm-0005ln-00@sc8-sf-web2.sourceforge.net>

Patches item #670390, was opened at 2003-01-18 20:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670390&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Vinay Sajip (vsajip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patched test harness for logging

Initial Comment:
I've attached test_logging.zip which contains a new 
version of test_logging.py as well as a new version of 
the output file (test_logging).

This moves the closing of a stream till after all the 
threads have completed.

Tested under ActivePython 2.1.1 build 212 under WinXP 
Home, the script now runs correctly both when run from 
the command line and when run under regrtest.

The script uses threads and so imports threading at the 
top. The script was causing a hang *only* when run via 
regrtest or the Python command prompt if run using 
import; I tracked the problem down to the 
ThreadingMixin's process_request method. When I 
copied this into the body of my derived class, it still 
failed; but commenting out the line "import threading" 
solved the problem, at least under WinXP 
Home/ActivePython 2.1.1 build 212. Can anyone shed 
any light on this?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-18 23:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670390&group_id=5470


From noreply@sourceforge.net  Sat Jan 18 23:26:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 15:26:58 -0800
Subject: [Patches] [ python-Patches-670423 ] Add missing identity tests to operator.c
Message-ID: <E18a2Mc-00079A-00@sc8-sf-web2.sourceforge.net>

Patches item #670423, was opened at 2003-01-18 15:14
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670423&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Add missing identity tests to operator.c

Initial Comment:
Define operator.is_ and operator.is_not.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 18:26

Message:
Logged In: YES 
user_id=80475

Modules/operator.c 2.27
Doc/lib/liboperator.c 1.26
Misc/NEWS 1.617
Lib/test/test_operator.py 1.11

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-18 17:47

Message:
Logged In: YES 
user_id=21627

The patch is fine, please apply it. Also add an entry to
Misc/NEWS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670423&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 00:04:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 16:04:36 -0800
Subject: [Patches] [ python-Patches-669553 ] fix memory (ref) leaks
Message-ID: <E18a2x2-0002Zg-00@sc8-sf-web4.sourceforge.net>

Patches item #669553, was opened at 2003-01-16 23:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669553&group_id=5470

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: fix memory (ref) leaks

Initial Comment:
Sorry, I'm lazy and this is a single patch to 2 files
to fix reference leaks.  

The int patch can be demonstrated by doing:

  abs(-2147483648)

The second happens when:

  import pyexpat
  p = pyexpat.ParserCreate()
  p.__members__


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 19:04

Message:
Logged In: YES 
user_id=80475

There is an error in the patch to intobject.c.  When 
o==NULL, then result is returned without having been set.  
A revised patch is attached.  Otherwise, it's okay:  I verified 
the leak fix and ran regression tests without exception.

The second patch checks out okay.  It might be cleaner 
and faster to alter the PyList_New for the correct number 
of entries and then just use PyList_SET_ITEM.  That saves 
the double INCDEF followed by a DECREF and it shortens 
the code a bit.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-17 05:44

Message:
Logged In: YES 
user_id=6656

Looks fine to me.

I haven't tested it, but I assume it compiles and the tests
pass.  I can't see how you could write a test for this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669553&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 00:27:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 16:27:04 -0800
Subject: [Patches] [ python-Patches-670390 ] Patched test harness for logging
Message-ID: <E18a3Im-00038N-00@sc8-sf-web4.sourceforge.net>

Patches item #670390, was opened at 2003-01-18 19:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670390&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Vinay Sajip (vsajip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patched test harness for logging

Initial Comment:
I've attached test_logging.zip which contains a new 
version of test_logging.py as well as a new version of 
the output file (test_logging).

This moves the closing of a stream till after all the 
threads have completed.

Tested under ActivePython 2.1.1 build 212 under WinXP 
Home, the script now runs correctly both when run from 
the command line and when run under regrtest.

The script uses threads and so imports threading at the 
top. The script was causing a hang *only* when run via 
regrtest or the Python command prompt if run using 
import; I tracked the problem down to the 
ThreadingMixin's process_request method. When I 
copied this into the body of my derived class, it still 
failed; but commenting out the line "import threading" 
solved the problem, at least under WinXP 
Home/ActivePython 2.1.1 build 212. Can anyone shed 
any light on this?


----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2003-01-19 00:27

Message:
Logged In: YES 
user_id=308438

Aaarrrgh! Sorry about the missing upload. Here it is 
(hopefully)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-18 22:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670390&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 00:49:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 16:49:10 -0800
Subject: [Patches] [ python-Patches-670229 ] doc improvement for cStringIO.h
Message-ID: <E18a3eA-0007W8-00@sc8-sf-web1.sourceforge.net>

Patches item #670229, was opened at 2003-01-18 06:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670229&group_id=5470

Category: Core (C code)
Group: Python 2.2.x
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Gernot Hillier (yoda_gh)
Assigned to: Raymond Hettinger (rhettinger)
Summary: doc improvement for cStringIO.h

Initial Comment:
I had some troubles in understanding the doc given in   
Include/cStringIO.h for the C API. So I looked into the source code   
and tried to improve it.   
   
Here's the result ;-)   
  
Made against 2.2.1, but checked it also applies against 2.2.2 
codebase. 

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 19:49

Message:
Logged In: YES 
user_id=80475

Accepted with minor fixups.
Applied as Include/cStringIO.h 2.20.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670229&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 01:07:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 17:07:21 -0800
Subject: [Patches] [ python-Patches-670367 ] Micro-optimizations for ceval.c
Message-ID: <E18a3vl-0003fT-00@sc8-sf-web3.sourceforge.net>

Patches item #670367, was opened at 2003-01-18 14:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Micro-optimizations for ceval.c

Initial Comment:
Make the code slightly shorter, faster, and easier to 
read.

* Eliminate unused DUP_TOPX code for x==1.  
compile.c always generates DUP_TOP instead.

* Since only two cases remain for DUP_TOPX, replace 
the switch-case with if-elseif.

* The in-lined integer compare does a CheckExact on 
both arguments.  Since the second is a little more 
likely to fail, test it first.

* The switch-case for IS/IS_NOT and IN/NOT_IN can 
separate the regular and inverted cases with no 
additional work.  For all four paths, saves a test and 
jump.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 20:07

Message:
Logged In: YES 
user_id=80475

These micro-optimizations are so small that they don't 
warrant setting-up timing code to show a 1% change.  
Neal's micro-optimizations were not individually tested and 
timed.  Likewise, Tim commented that these are all steps 
in the right direction even if they can't be individually 
timed. OTOH, if any of these look like a step backwards, 
they ought to be zapped. All that being said, I would still 
make a timing suite if weren't so difficult to get consistent 
timings on WindowsME.

The benefit for the switch-case is observable in the 
assembly output which shows one-fewer test jump on 
every path and no other changes.

The elimination of an unused case for dup_topx is a 
continuation of what GvR okayed on python-dev.  There is 
a slight savings in code volume.  There will be no time 
saved because the code was never called.

The conversion from switch-case to if-else follows the 
recommendations from Intel's Software Optimization 
Cookbook.  It says that the if-else form has a chance at 
branch prediction, while the calculated jump does not.  
More importantly, the code is just a little bit clearer than 
the 2 case switch.

Changing the order of the PyInt_CheckExact tests came 
from the observation that "anInt in aContainer" would pass 
the first test but not the second.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-18 17:52

Message:
Logged In: YES 
user_id=21627

What kind of speed-up have you observed for what test case?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 01:40:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 17:40:30 -0800
Subject: [Patches] [ python-Patches-670367 ] Micro-optimizations for ceval.c
Message-ID: <E18a4Rq-0004U6-00@sc8-sf-web3.sourceforge.net>

Patches item #670367, was opened at 2003-01-18 14:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Micro-optimizations for ceval.c

Initial Comment:
Make the code slightly shorter, faster, and easier to 
read.

* Eliminate unused DUP_TOPX code for x==1.  
compile.c always generates DUP_TOP instead.

* Since only two cases remain for DUP_TOPX, replace 
the switch-case with if-elseif.

* The in-lined integer compare does a CheckExact on 
both arguments.  Since the second is a little more 
likely to fail, test it first.

* The switch-case for IS/IS_NOT and IN/NOT_IN can 
separate the regular and inverted cases with no 
additional work.  For all four paths, saves a test and 
jump.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 20:40

Message:
Logged In: YES 
user_id=80475

The attached timing code shows about a 7% speed-up for 
the IS test.  I didn't expect this much but then IS is a low 
overhead test.

The same test for IS NOT shows 5%.

The same test for "5 in []" shows only 1%.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 20:07

Message:
Logged In: YES 
user_id=80475

These micro-optimizations are so small that they don't 
warrant setting-up timing code to show a 1% change.  
Neal's micro-optimizations were not individually tested and 
timed.  Likewise, Tim commented that these are all steps 
in the right direction even if they can't be individually 
timed. OTOH, if any of these look like a step backwards, 
they ought to be zapped. All that being said, I would still 
make a timing suite if weren't so difficult to get consistent 
timings on WindowsME.

The benefit for the switch-case is observable in the 
assembly output which shows one-fewer test jump on 
every path and no other changes.

The elimination of an unused case for dup_topx is a 
continuation of what GvR okayed on python-dev.  There is 
a slight savings in code volume.  There will be no time 
saved because the code was never called.

The conversion from switch-case to if-else follows the 
recommendations from Intel's Software Optimization 
Cookbook.  It says that the if-else form has a chance at 
branch prediction, while the calculated jump does not.  
More importantly, the code is just a little bit clearer than 
the 2 case switch.

Changing the order of the PyInt_CheckExact tests came 
from the observation that "anInt in aContainer" would pass 
the first test but not the second.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-18 17:52

Message:
Logged In: YES 
user_id=21627

What kind of speed-up have you observed for what test case?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 01:50:49 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 17:50:49 -0800
Subject: [Patches] [ python-Patches-670367 ] Micro-optimizations for ceval.c
Message-ID: <E18a4bp-0000d3-00@sc8-sf-web1.sourceforge.net>

Patches item #670367, was opened at 2003-01-18 14:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Micro-optimizations for ceval.c

Initial Comment:
Make the code slightly shorter, faster, and easier to 
read.

* Eliminate unused DUP_TOPX code for x==1.  
compile.c always generates DUP_TOP instead.

* Since only two cases remain for DUP_TOPX, replace 
the switch-case with if-elseif.

* The in-lined integer compare does a CheckExact on 
both arguments.  Since the second is a little more 
likely to fail, test it first.

* The switch-case for IS/IS_NOT and IN/NOT_IN can 
separate the regular and inverted cases with no 
additional work.  For all four paths, saves a test and 
jump.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 20:50

Message:
Logged In: YES 
user_id=80475

Typo in the last message:

The savings for "5 in []" is 4%.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 20:40

Message:
Logged In: YES 
user_id=80475

The attached timing code shows about a 7% speed-up for 
the IS test.  I didn't expect this much but then IS is a low 
overhead test.

The same test for IS NOT shows 5%.

The same test for "5 in []" shows only 1%.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 20:07

Message:
Logged In: YES 
user_id=80475

These micro-optimizations are so small that they don't 
warrant setting-up timing code to show a 1% change.  
Neal's micro-optimizations were not individually tested and 
timed.  Likewise, Tim commented that these are all steps 
in the right direction even if they can't be individually 
timed. OTOH, if any of these look like a step backwards, 
they ought to be zapped. All that being said, I would still 
make a timing suite if weren't so difficult to get consistent 
timings on WindowsME.

The benefit for the switch-case is observable in the 
assembly output which shows one-fewer test jump on 
every path and no other changes.

The elimination of an unused case for dup_topx is a 
continuation of what GvR okayed on python-dev.  There is 
a slight savings in code volume.  There will be no time 
saved because the code was never called.

The conversion from switch-case to if-else follows the 
recommendations from Intel's Software Optimization 
Cookbook.  It says that the if-else form has a chance at 
branch prediction, while the calculated jump does not.  
More importantly, the code is just a little bit clearer than 
the 2 case switch.

Changing the order of the PyInt_CheckExact tests came 
from the observation that "anInt in aContainer" would pass 
the first test but not the second.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-18 17:52

Message:
Logged In: YES 
user_id=21627

What kind of speed-up have you observed for what test case?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 03:00:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 19:00:52 -0800
Subject: [Patches] [ python-Patches-669553 ] fix memory (ref) leaks
Message-ID: <E18a5hc-0006us-00@sc8-sf-web4.sourceforge.net>

Patches item #669553, was opened at 2003-01-16 23:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669553&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: fix memory (ref) leaks

Initial Comment:
Sorry, I'm lazy and this is a single patch to 2 files
to fix reference leaks.  

The int patch can be demonstrated by doing:

  abs(-2147483648)

The second happens when:

  import pyexpat
  p = pyexpat.ParserCreate()
  p.__members__


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 22:00

Message:
Logged In: YES 
user_id=80475

When the patches are fixed-up, they should also be 
backported.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 19:04

Message:
Logged In: YES 
user_id=80475

There is an error in the patch to intobject.c.  When 
o==NULL, then result is returned without having been set.  
A revised patch is attached.  Otherwise, it's okay:  I verified 
the leak fix and ran regression tests without exception.

The second patch checks out okay.  It might be cleaner 
and faster to alter the PyList_New for the correct number 
of entries and then just use PyList_SET_ITEM.  That saves 
the double INCDEF followed by a DECREF and it shortens 
the code a bit.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-17 05:44

Message:
Logged In: YES 
user_id=6656

Looks fine to me.

I haven't tested it, but I assume it compiles and the tests
pass.  I can't see how you could write a test for this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669553&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 03:04:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 19:04:48 -0800
Subject: [Patches] [ python-Patches-636005 ] Filter unicode into unicode
Message-ID: <E18a5lQ-0006z4-00@sc8-sf-web4.sourceforge.net>

Patches item #636005, was opened at 2002-11-09 15:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=636005&group_id=5470

Category: Core (C code)
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Filter unicode into unicode

Initial Comment:
Currently, filter(None, "abc") gives "abc", but
filter(None, u"abc") gives [u'a', u'b', u'c']. This
patches corrects this, adding a Unicode specical case
for filter.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 22:04

Message:
Logged In: YES 
user_id=80475

Do you still have this patch available?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-11-11 04:11

Message:
Logged In: YES 
user_id=38388

There's no patch attached to this SF item, but
you're right, filter() should behave in the same
way for 8-bit strings as for Unicode.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=636005&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 03:12:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 19:12:23 -0800
Subject: [Patches] [ python-Patches-634866 ] general corrections to 2.2.2 refman, p.1
Message-ID: <E18a5sl-0004nb-00@sc8-sf-web2.sourceforge.net>

Patches item #634866, was opened at 2002-11-07 03:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=634866&group_id=5470

Category: Documentation
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: general corrections to 2.2.2 refman, p.1

Initial Comment:
as per email exchanges with F. Drake, here's a first part of 
suggested corrections to the 2.2.2 reference manual, mostly 
to make it reflect a bit better the way Python currently works.


----------------------------------------------------------------------

Comment By: Alex Martelli (aleax)
Date: 2002-11-16 18:16

Message:
Logged In: YES 
user_id=60314

OK, corrected my mistakes and nuked all \C, e.g. and i.e. from 
chapters 2, 3, 6 (the chapters affected by the patch).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-11-13 15:07

Message:
Logged In: YES 
user_id=3066

Alex, a few nits:

- In the first chunk, I suspect you meant "triple-quoted
string literal", not "raw string literal".

- "e.g." and "i.e." should be avoided with great prejudice.
 I've been removing them from the rest of the documentation
as I've had time.

- "\C" and "\C{}" should both be replaced with just "C"
whenever found.

- When you refer to the "C or Java implementation", realize
that the Java implementation is more deterministic; Java
ints are 32 bits, period, IIRC.

- There is not __iterkeys__(), only iterkeys().

I have not tried applying the patch to test formatting.

Ok, it sounds like a lot of things, but they're all rather
small.  Your patch really helps; thanks!

If you can make these changes and post an updated patch, it
shouldn't take long to get it committed.  I've marked the
patch "pending" since I'm waiting for changes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=634866&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 03:50:31 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 19:50:31 -0800
Subject: [Patches] [ python-Patches-670367 ] Micro-optimizations for ceval.c
Message-ID: <E18a6Tf-0005bl-00@sc8-sf-web2.sourceforge.net>

Patches item #670367, was opened at 2003-01-18 14:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470

Category: None
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Micro-optimizations for ceval.c

Initial Comment:
Make the code slightly shorter, faster, and easier to 
read.

* Eliminate unused DUP_TOPX code for x==1.  
compile.c always generates DUP_TOP instead.

* Since only two cases remain for DUP_TOPX, replace 
the switch-case with if-elseif.

* The in-lined integer compare does a CheckExact on 
both arguments.  Since the second is a little more 
likely to fail, test it first.

* The switch-case for IS/IS_NOT and IN/NOT_IN can 
separate the regular and inverted cases with no 
additional work.  For all four paths, saves a test and 
jump.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-01-18 22:50

Message:
Logged In: YES 
user_id=31435

Small non-obscure changes that reduce instruction count 
(etc) can be made even if timing shows a slowdown.  This is 
extremely dependent on platform-specific and compiler 
release-specific compiler optimization, and ceval.c is so 
complex it kicks every linear-time optimizer into 
unpredictable behavior,  It's the accumulation, over time, of 
many small changes "in the right direction" that pays off 
over time.  On the way there, timing will bounce around 
seemingly at random, and in different ways under different 
compilers and architectures.  Don't sweat it -- I don't, and 
I've done as much to speed Python as anyone <wink>.

Marked Accepted and back to Raymond.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 20:50

Message:
Logged In: YES 
user_id=80475

Typo in the last message:

The savings for "5 in []" is 4%.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 20:40

Message:
Logged In: YES 
user_id=80475

The attached timing code shows about a 7% speed-up for 
the IS test.  I didn't expect this much but then IS is a low 
overhead test.

The same test for IS NOT shows 5%.

The same test for "5 in []" shows only 1%.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 20:07

Message:
Logged In: YES 
user_id=80475

These micro-optimizations are so small that they don't 
warrant setting-up timing code to show a 1% change.  
Neal's micro-optimizations were not individually tested and 
timed.  Likewise, Tim commented that these are all steps 
in the right direction even if they can't be individually 
timed. OTOH, if any of these look like a step backwards, 
they ought to be zapped. All that being said, I would still 
make a timing suite if weren't so difficult to get consistent 
timings on WindowsME.

The benefit for the switch-case is observable in the 
assembly output which shows one-fewer test jump on 
every path and no other changes.

The elimination of an unused case for dup_topx is a 
continuation of what GvR okayed on python-dev.  There is 
a slight savings in code volume.  There will be no time 
saved because the code was never called.

The conversion from switch-case to if-else follows the 
recommendations from Intel's Software Optimization 
Cookbook.  It says that the if-else form has a chance at 
branch prediction, while the calculated jump does not.  
More importantly, the code is just a little bit clearer than 
the 2 case switch.

Changing the order of the PyInt_CheckExact tests came 
from the observation that "anInt in aContainer" would pass 
the first test but not the second.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-18 17:52

Message:
Logged In: YES 
user_id=21627

What kind of speed-up have you observed for what test case?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 04:44:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 20:44:51 -0800
Subject: [Patches] [ python-Patches-670194 ] Performance enhancement for _strptime.py
Message-ID: <E18a7KF-0000Zb-00@sc8-sf-web3.sourceforge.net>

Patches item #670194, was opened at 2003-01-18 02:45
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670194&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Brett Cannon (bcannon)
>Assigned to: Tim Peters (tim_one)
Summary: Performance enhancement for _strptime.py

Initial Comment:
Using a suggestion from Tim Peters (see http://mail.python.org/pipermail/python-dev/2003-January/032177.html for the e-mail where Tim makes his suggestion), I have added some code to _strptime.py to enhance its performance.  Specifically, I now cache a TimeRE instance and a dict containing compiled regex objects.  The TimeRE instance prevents rediscovery of locale info when the user does not change the language.  The regex object cache prevents the need to recompile regex objects when the same format string is used again and again.  Both are cleared when the language is changed.

I moved the language discovery code to a module-level function so as to make checking the current language easier.

I also removed the one use of the string module I had (has it been decided how something like string.whitespace is going to be replaced, or is that not a concern?).

I didn't bother writing any tests for this since the code changes are so simple and any breakage would have been discovered by the current tests.  But if there is a desire for tests I will do them.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-01-18 23:44

Message:
Logged In: YES 
user_id=31435

Checked in, as Lib/_strptime.py; new revision: 1.11.  
Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670194&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 05:12:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 18 Jan 2003 21:12:06 -0800
Subject: [Patches] [ python-Patches-670367 ] Micro-optimizations for ceval.c
Message-ID: <E18a7kc-0005tH-00@sc8-sf-web1.sourceforge.net>

Patches item #670367, was opened at 2003-01-18 14:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470

Category: None
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Micro-optimizations for ceval.c

Initial Comment:
Make the code slightly shorter, faster, and easier to 
read.

* Eliminate unused DUP_TOPX code for x==1.  
compile.c always generates DUP_TOP instead.

* Since only two cases remain for DUP_TOPX, replace 
the switch-case with if-elseif.

* The in-lined integer compare does a CheckExact on 
both arguments.  Since the second is a little more 
likely to fail, test it first.

* The switch-case for IS/IS_NOT and IN/NOT_IN can 
separate the regular and inverted cases with no 
additional work.  For all four paths, saves a test and 
jump.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-19 00:12

Message:
Logged In: YES 
user_id=80475

Applied as Python/ceval.c 2.347.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-18 22:50

Message:
Logged In: YES 
user_id=31435

Small non-obscure changes that reduce instruction count 
(etc) can be made even if timing shows a slowdown.  This is 
extremely dependent on platform-specific and compiler 
release-specific compiler optimization, and ceval.c is so 
complex it kicks every linear-time optimizer into 
unpredictable behavior,  It's the accumulation, over time, of 
many small changes "in the right direction" that pays off 
over time.  On the way there, timing will bounce around 
seemingly at random, and in different ways under different 
compilers and architectures.  Don't sweat it -- I don't, and 
I've done as much to speed Python as anyone <wink>.

Marked Accepted and back to Raymond.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 20:50

Message:
Logged In: YES 
user_id=80475

Typo in the last message:

The savings for "5 in []" is 4%.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 20:40

Message:
Logged In: YES 
user_id=80475

The attached timing code shows about a 7% speed-up for 
the IS test.  I didn't expect this much but then IS is a low 
overhead test.

The same test for IS NOT shows 5%.

The same test for "5 in []" shows only 1%.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 20:07

Message:
Logged In: YES 
user_id=80475

These micro-optimizations are so small that they don't 
warrant setting-up timing code to show a 1% change.  
Neal's micro-optimizations were not individually tested and 
timed.  Likewise, Tim commented that these are all steps 
in the right direction even if they can't be individually 
timed. OTOH, if any of these look like a step backwards, 
they ought to be zapped. All that being said, I would still 
make a timing suite if weren't so difficult to get consistent 
timings on WindowsME.

The benefit for the switch-case is observable in the 
assembly output which shows one-fewer test jump on 
every path and no other changes.

The elimination of an unused case for dup_topx is a 
continuation of what GvR okayed on python-dev.  There is 
a slight savings in code volume.  There will be no time 
saved because the code was never called.

The conversion from switch-case to if-else follows the 
recommendations from Intel's Software Optimization 
Cookbook.  It says that the if-else form has a chance at 
branch prediction, while the calculated jump does not.  
More importantly, the code is just a little bit clearer than 
the 2 case switch.

Changing the order of the PyInt_CheckExact tests came 
from the observation that "anInt in aContainer" would pass 
the first test but not the second.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-18 17:52

Message:
Logged In: YES 
user_id=21627

What kind of speed-up have you observed for what test case?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670367&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 13:12:28 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 19 Jan 2003 05:12:28 -0800
Subject: [Patches] [ python-Patches-634866 ] general corrections to 2.2.2 refman, p.1
Message-ID: <E18aFFU-0002at-00@sc8-sf-web1.sourceforge.net>

Patches item #634866, was opened at 2002-11-07 03:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=634866&group_id=5470

Category: Documentation
Group: Python 2.2.x
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Raymond Hettinger (rhettinger)
Summary: general corrections to 2.2.2 refman, p.1

Initial Comment:
as per email exchanges with F. Drake, here's a first part of 
suggested corrections to the 2.2.2 reference manual, mostly 
to make it reflect a bit better the way Python currently works.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-19 08:12

Message:
Logged In: YES 
user_id=80475

Reviewed diff, fixed markup, add Py2.3 features, clipped a 
couple more \C{}, removed more i.e. and e.g.  and applied 
to Python2.3 with a note to backport.

See ref2.tex 1.47, ref3.tex 1.97, and ref6.tex 1.61.


----------------------------------------------------------------------

Comment By: Alex Martelli (aleax)
Date: 2002-11-16 18:16

Message:
Logged In: YES 
user_id=60314

OK, corrected my mistakes and nuked all \C, e.g. and i.e. from 
chapters 2, 3, 6 (the chapters affected by the patch).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-11-13 15:07

Message:
Logged In: YES 
user_id=3066

Alex, a few nits:

- In the first chunk, I suspect you meant "triple-quoted
string literal", not "raw string literal".

- "e.g." and "i.e." should be avoided with great prejudice.
 I've been removing them from the rest of the documentation
as I've had time.

- "\C" and "\C{}" should both be replaced with just "C"
whenever found.

- When you refer to the "C or Java implementation", realize
that the Java implementation is more deterministic; Java
ints are 32 bits, period, IIRC.

- There is not __iterkeys__(), only iterkeys().

I have not tried applying the patch to test formatting.

Ok, it sounds like a lot of things, but they're all rather
small.  Your patch really helps; thanks!

If you can make these changes and post an updated patch, it
shouldn't take long to get it committed.  I've marked the
patch "pending" since I'm waiting for changes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=634866&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 13:26:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 19 Jan 2003 05:26:07 -0800
Subject: [Patches] [ python-Patches-634557 ] Better inspect.BlockFinder fixes bug
Message-ID: <E18aFSh-0008F8-00@sc8-sf-web4.sourceforge.net>

Patches item #634557, was opened at 2002-11-06 13:04
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=634557&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Patrick K. O'Brien (pobrien)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better inspect.BlockFinder fixes bug

Initial Comment:
inspect.BlockFinder didn't do a good enough job finding  
the end of code blocks. This can be observed by  
running:  
  
>>> import inspect  
>>> import tokenize  
>>> print inspect.getsource(tokenize.TokenError)  
class TokenError(Exception): pass  
  
class StopTokenizing(Exception): pass  
  
def printtoken(type, token, (srow, scol), (erow, ecol),  
line): # for testing  
    print "%d,%d-%d,%d:\t%s\t%s" % \  
        (srow, scol, erow, ecol, tok_name[type],  
repr(token))  
  
>>>   
  
Notice how it picks up extra source code lines. The  
attached patch fixes this problem. There should probably 
be some additional unit tests for this, but I ran out of time 
and energy. 

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-19 08:26

Message:
Logged In: YES 
user_id=80475

I spent a little time testing this one and checked to make 
sure it didn't clash with my fixes.

Marking as accepted and applying as Lib/inspect 1.41.

----------------------------------------------------------------------

Comment By: Patrick K. O'Brien (pobrien)
Date: 2002-11-06 17:55

Message:
Logged In: YES 
user_id=179604

Yes, this does fix bug # 595018. I'll look at the other inspect 
module bugs when I've got some spare time. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-11-06 17:41

Message:
Logged In: YES 
user_id=33168

Does this fix bug # 595018?  There are a few other inspect
module bugs I think.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=634557&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 14:07:07 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 19 Jan 2003 06:07:07 -0800
Subject: [Patches] [ python-Patches-670664 ] HTMLParser.py - more robust <SCRIPT> parsing
Message-ID: <E18aG6N-0004Su-00@sc8-sf-web1.sourceforge.net>

Patches item #670664, was opened at 2003-01-19 14:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTMLParser.py - more robust <SCRIPT> parsing

Initial Comment:
http://www.ebay.com contains a script element of the form

<SCRIPT>
...
   vbscript += "</SCR"+"IPT> \n";
...
</SCRIPT>

which is not enclosed in "<!-- ... -->" comments.  The parser 
choked on that line, indicating it was a mal-formed end tag.

The changes are:

  interesting_cdata is now a dict mapping start tag to
    an re matching the end tag, a "<--" or \Z

  HTMLParser.set_cdata_mode takes an extra argument, 
    the start tag


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 14:46:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 19 Jan 2003 06:46:05 -0800
Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest
Message-ID: <E18aGi5-0007Lk-00@sc8-sf-web2.sourceforge.net>

Patches item #662807, was opened at 2003-01-05 15:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Port tests to unittest

Initial Comment:
This patch ports the three tests test_pow.py, 
test_charmapcodec.py and test_userdict.py to unittest.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-19 09:46

Message:
Logged In: YES 
user_id=80475

All are approved except test_charmapcodec.py -- 
someone else should look at that one.

Be sure to follow GvR's advice and replace assertEquals 
with assertEqual.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-16 15:47

Message:
Logged In: YES 
user_id=89016

test_unicode is ported and enhanced (coverage goes from
80.81% to 85.05%)

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-10 12:17

Message:
Logged In: YES 
user_id=89016

> In general, don't do tests that hardwire implementation 
details

So should we remove
self.assertEquals(reduce(42, "1"), "1")
self.assertEquals(reduce(42, "", "1"), "1")
from test_filter?

BTW, you should look at test_builtin first, as the others
are still simply ports to PyUnit.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-10 12:03

Message:
Logged In: YES 
user_id=80475

Good to hear the news on increasing the coverage.

In general, don't do tests that hardwire implementation 
details.  Test it if it is a documented variable,  exposed 
through __all__, is a key constact (like the magic numbers 
in random.py), or a variable that a module user is likely to 
be relying upon.  Otherwise, no -- it should be possible to 
improve an implementation without crashing the suite.

I'll try to review a few of these over the next few days.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-10 11:53

Message:
Logged In: YES 
user_id=89016

test_builtin.py is now updated to test more error
situations. This increases the coverage of bltinmodule.c
from 75.13% to 92.20%, and it actually revealed one or two
potential bugs:
http://www.python.org/sf/665761 and
http://www.python.org/sf/665835

I'm not 100% sure that test_intern() and test_execfile() do
the right thing.

I'm not sure, whether the test script should check for
undocumented implementation artefacts, like:

a = 1
self.assert_(min(a, 1L) is a)

but in this way at least we get notified if something is
changed unintentionally.


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-08 14:05

Message:
Logged In: YES 
user_id=89016

test_b1 and test_b2 are combined into test_builtin now

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 09:03

Message:
Logged In: YES 
user_id=6380

Two random suggestions:

- a blank line before each method, even trivial ones, even
the first one

- use assertEqual, not assertEquals

BTW, I see you've picked up on the convention that unit test
methods should not have doc strings. Good! (But they may
have comments.)

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-07 11:37

Message:
Logged In: YES 
user_id=89016

test_b1.py has been ported too.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-05 15:56

Message:
Logged In: YES 
user_id=89016

The patch is hard to read, so I'll upload all three test scripts.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 14:46:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 19 Jan 2003 06:46:35 -0800
Subject: [Patches] [ python-Patches-662807 ] Port tests to unittest
Message-ID: <E18aGiZ-0007MI-00@sc8-sf-web2.sourceforge.net>

Patches item #662807, was opened at 2003-01-05 15:50
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470

Category: Tests
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: Walter Dörwald (doerwalter)
Summary: Port tests to unittest

Initial Comment:
This patch ports the three tests test_pow.py, 
test_charmapcodec.py and test_userdict.py to unittest.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-19 09:46

Message:
Logged In: YES 
user_id=80475

All are approved except test_charmapcodec.py -- 
someone else should look at that one.

Be sure to follow GvR's advice and replace assertEquals 
with assertEqual.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-16 15:47

Message:
Logged In: YES 
user_id=89016

test_unicode is ported and enhanced (coverage goes from
80.81% to 85.05%)

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-10 12:17

Message:
Logged In: YES 
user_id=89016

> In general, don't do tests that hardwire implementation 
details

So should we remove
self.assertEquals(reduce(42, "1"), "1")
self.assertEquals(reduce(42, "", "1"), "1")
from test_filter?

BTW, you should look at test_builtin first, as the others
are still simply ports to PyUnit.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-10 12:03

Message:
Logged In: YES 
user_id=80475

Good to hear the news on increasing the coverage.

In general, don't do tests that hardwire implementation 
details.  Test it if it is a documented variable,  exposed 
through __all__, is a key constact (like the magic numbers 
in random.py), or a variable that a module user is likely to 
be relying upon.  Otherwise, no -- it should be possible to 
improve an implementation without crashing the suite.

I'll try to review a few of these over the next few days.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-10 11:53

Message:
Logged In: YES 
user_id=89016

test_builtin.py is now updated to test more error
situations. This increases the coverage of bltinmodule.c
from 75.13% to 92.20%, and it actually revealed one or two
potential bugs:
http://www.python.org/sf/665761 and
http://www.python.org/sf/665835

I'm not 100% sure that test_intern() and test_execfile() do
the right thing.

I'm not sure, whether the test script should check for
undocumented implementation artefacts, like:

a = 1
self.assert_(min(a, 1L) is a)

but in this way at least we get notified if something is
changed unintentionally.


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-08 14:05

Message:
Logged In: YES 
user_id=89016

test_b1 and test_b2 are combined into test_builtin now

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-08 09:03

Message:
Logged In: YES 
user_id=6380

Two random suggestions:

- a blank line before each method, even trivial ones, even
the first one

- use assertEqual, not assertEquals

BTW, I see you've picked up on the convention that unit test
methods should not have doc strings. Good! (But they may
have comments.)

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-07 11:37

Message:
Logged In: YES 
user_id=89016

test_b1.py has been ported too.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-05 15:56

Message:
Logged In: YES 
user_id=89016

The patch is hard to read, so I'll upload all three test scripts.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=662807&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 15:52:21 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 19 Jan 2003 07:52:21 -0800
Subject: [Patches] [ python-Patches-669553 ] fix memory (ref) leaks
Message-ID: <E18aHkD-0000ng-00@sc8-sf-web2.sourceforge.net>

Patches item #669553, was opened at 2003-01-16 23:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669553&group_id=5470

Category: None
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: fix memory (ref) leaks

Initial Comment:
Sorry, I'm lazy and this is a single patch to 2 files
to fix reference leaks.  

The int patch can be demonstrated by doing:

  abs(-2147483648)

The second happens when:

  import pyexpat
  p = pyexpat.ParserCreate()
  p.__members__


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-19 10:52

Message:
Logged In: YES 
user_id=33168

Raymond, you are correct about the problem in intobject.  I
agree about that it could be cleaner to use PyList_New, but
I'm not making the change now.  Just trying to make things
correct (and I'm too lazy :-).

Michael, these could be tested with pydebug builds, if
sys.getrefcount() was captured before and verified it was
correct after calling the code to test/exercise the
problems.  I'm not sure it's worth it, though.

Checked in as:
  intobject.c 2.99 and 2.79.6.6
  pyexpat.c  2.77 and 2.57.6.5

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 22:00

Message:
Logged In: YES 
user_id=80475

When the patches are fixed-up, they should also be 
backported.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 19:04

Message:
Logged In: YES 
user_id=80475

There is an error in the patch to intobject.c.  When 
o==NULL, then result is returned without having been set.  
A revised patch is attached.  Otherwise, it's okay:  I verified 
the leak fix and ran regression tests without exception.

The second patch checks out okay.  It might be cleaner 
and faster to alter the PyList_New for the correct number 
of entries and then just use PyList_SET_ITEM.  That saves 
the double INCDEF followed by a DECREF and it shortens 
the code a bit.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-17 05:44

Message:
Logged In: YES 
user_id=6656

Looks fine to me.

I haven't tested it, but I assume it compiles and the tests
pass.  I can't see how you could write a test for this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669553&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 16:51:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 19 Jan 2003 08:51:35 -0800
Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv
Message-ID: <E18aIfX-0002xR-00@sc8-sf-web2.sourceforge.net>

Patches item #670715, was opened at 2003-01-20 01:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal Unicode Codec for POSIX iconv

Initial Comment:
Here's the unicode codec using POSIX iconv(3) library.

Tested on these platforms and seems to work:
  FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64,
  FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2

This codec implementation supports PEP293, also.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 22:56:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 19 Jan 2003 14:56:35 -0800
Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv
Message-ID: <E18aOMl-00072e-00@sc8-sf-web1.sourceforge.net>

Patches item #670715, was opened at 2003-01-19 17:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal Unicode Codec for POSIX iconv

Initial Comment:
Here's the unicode codec using POSIX iconv(3) library.

Tested on these platforms and seems to work:
  FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64,
  FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2

This codec implementation supports PEP293, also.


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-19 23:56

Message:
Logged In: YES 
user_id=38388

The patch looks good, but you'll need to add some form
of testing to underline the "seems to work" :-)

Some docs on how to use the codec would also be needed.

Martin von Loewis has written a similar codec some months ago.
Perhaps you two could get in touch and sort out the details ?!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470


From noreply@sourceforge.net  Sun Jan 19 23:58:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 19 Jan 2003 15:58:04 -0800
Subject: [Patches] [ python-Patches-658316 ] skips.txt for regrtest.py
Message-ID: <E18aPKG-0003O9-00@sc8-sf-web3.sourceforge.net>

Patches item #658316, was opened at 2002-12-24 12:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658316&group_id=5470

>Category: Tests
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Nobody/Anonymous (nobody)
Summary: skips.txt for regrtest.py

Initial Comment:
As I promised on python-dev here is the functionality
to have  a skips.txt file for regrtest.py.  If the file
is present in the current directory it is parsed (using
the exact same code as used for  the -f option for
regrtest; good, old copy-n-paste) and all tests are
added to the expected skip set.

And as commented in the file, the name of the file is
so named after Skip Montanaro because he is too shy.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2002-12-29 17:37

Message:
Logged In: YES 
user_id=357491

Oops.  =)

New diff includes a paragraph at the end of the module
documentation that mentions how to use the new functionality.

Please delete the old diff.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-12-28 21:09

Message:
Logged In: YES 
user_id=80475

The patch looks good.
Now, it needs documentation.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2002-12-26 13:04

Message:
Logged In: YES 
user_id=357491

Sorry about that!  I could have sworn I checked the box.  I
have uploaded enough files here you would think it would be
habitual by now.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-26 10:10

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658316&group_id=5470


From noreply@sourceforge.net  Mon Jan 20 13:33:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 20 Jan 2003 05:33:34 -0800
Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv
Message-ID: <E18ac3S-0001BB-00@sc8-sf-web2.sourceforge.net>

Patches item #670715, was opened at 2003-01-20 01:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Universal Unicode Codec for POSIX iconv

Initial Comment:
Here's the unicode codec using POSIX iconv(3) library.

Tested on these platforms and seems to work:
  FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64,
  FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2

This codec implementation supports PEP293, also.


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2003-01-20 22:33

Message:
Logged In: YES 
user_id=55188

Thank you for comments. :->
I uploaded a new revised patch with unittest and some code
style fixes.

I saw Martin v. Loewis's iconvcodecs about a years ago.
His implementation is very neat, but it had a limit on error
handling due to recursive call.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-20 07:56

Message:
Logged In: YES 
user_id=38388

The patch looks good, but you'll need to add some form
of testing to underline the "seems to work" :-)

Some docs on how to use the codec would also be needed.

Martin von Loewis has written a similar codec some months ago.
Perhaps you two could get in touch and sort out the details ?!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470


From noreply@sourceforge.net  Mon Jan 20 14:13:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 20 Jan 2003 06:13:12 -0800
Subject: [Patches] [ python-Patches-671176 ] Compile _randommodule.c and datetimemodule.c under cygwin
Message-ID: <E18acfo-0002jR-00@sc8-sf-web2.sourceforge.net>

Patches item #671176, was opened at 2003-01-20 16:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671176&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compile _randommodule.c and datetimemodule.c under cygwin

Initial Comment:
Currently _randommodule.c and datetimemodule.c won't
compile under cygwin. The usual 'Not a const' error.

Attached is tar with both diffs

Miki

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671176&group_id=5470


From noreply@sourceforge.net  Mon Jan 20 14:46:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 20 Jan 2003 06:46:02 -0800
Subject: [Patches] [ python-Patches-671176 ] Compile _randommodule.c and datetimemodule.c under cygwin
Message-ID: <E18adBa-0004Ij-00@sc8-sf-web2.sourceforge.net>

Patches item #671176, was opened at 2003-01-20 09:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671176&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compile _randommodule.c and datetimemodule.c under cygwin

Initial Comment:
Currently _randommodule.c and datetimemodule.c won't
compile under cygwin. The usual 'Not a const' error.

Attached is tar with both diffs

Miki

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-20 09:46

Message:
Logged In: YES 
user_id=33168

There's no file attached.  These changes may not be
necessary based on changes Jason Tishler has made.   See
http://python.org/sf/661760



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671176&group_id=5470


From noreply@sourceforge.net  Mon Jan 20 20:44:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 20 Jan 2003 12:44:16 -0800
Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory
Message-ID: <E18aimG-0003YY-00@sc8-sf-web4.sourceforge.net>

Patches item #661796, was opened at 2003-01-03 19:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: BZ2File leaking fd and memory

Initial Comment:
The attached patch fixes BZ2File() leaking the fd and
PyFileObject* info (name, read ahead buffer) when an
object is deleted.

I'm not sure the patch fixes these problems in the best
way.  It exposes most of the implementation from
fileobject.c::file_dealloc() through a private API
_PyFile_Dealloc().
BZ2File derives from PyFileObject.

Make sure the file: 'empty' exists and do: 

  from bz2 import *

A simple test which demonstrates the problem is:

  for i in range(100000): o = BZ2File('empty') ; del o

Without the patch, you quickly get:

IOError: [Errno 24] Too many open files: 'empty'

You can modify this to:

  for i in range(100000): o = BZ2File('empty') ;
o.close() ; del o

Now you can see the memory leaks.


----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-01-20 20:44

Message:
Logged In: YES 
user_id=7887

Sorry about the delay. I was on a not-so-short vacation.

nnorwitz:

Thanks for the patch. I'll check the problem (for my own
understanding) and most certainly apply it.

gvanrossum:

BZ2File used to share a lot of code with FileObject.
Unfortunately (for the BZ2File side), FileObject changed
considerably post 2.2, and some of the code had to be moved
to BZ2File itself. It still
uses some code from FileObject, though (open, close, seek,
part of the softspace handling, access to attributes and
some common methods).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-05 21:11

Message:
Logged In: YES 
user_id=6380

Um, I don't understand why the BZ2File class inherits from
FileObject. It doesn't seem to be inheriting any code, and
there's no reason to inherit from FileObject just to make a
file-like object. Maybe it was a misunderstanding?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-05 20:09

Message:
Logged In: YES 
user_id=33168

I've found a better solution: change the last line of
BZ2File_dealloc() from: 
  ((PyObject*)self)->ob_type->tp_free((PyObject *)self);

to
  PyFile_Type.tp_dealloc((PyObject *)self);
Updated patch attached.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 19:48

Message:
Logged In: YES 
user_id=21627

Assigning to the author of the module for review. Gustavo,
if you can't find the time for a review, feel free to
unassign it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470


From noreply@sourceforge.net  Mon Jan 20 21:23:20 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 20 Jan 2003 13:23:20 -0800
Subject: [Patches] [ python-Patches-671384 ] test_pty hanging on hpux11
Message-ID: <E18ajO4-0007gl-00@sc8-sf-web2.sourceforge.net>

Patches item #671384, was opened at 2003-01-20 16:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671384&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_pty hanging on hpux11

Initial Comment:
The attached hack fixes a problem which occurs since
switching the pty code.  isatty() hangs if the slave_fd
is closed and reopened as in the deprecated APIs
pty.master_open() and pty.slave_open().

This patch reverts to the old behaviour where
_open_terminal() is called in master_open() to avoid
the hang later.

Here's a very simple test for the problem:

import pty, os

master_fd, slave_name = pty.master_open()
slave_fd = pty.slave_open(slave_name)
print os.isatty(slave_fd)

In slave_open() the first ioctl raises an IOError,
Invalid Argument 22.

I don't know if this problem affects hpux10.  Hopefully
someone will have a better idea how to really fix this
problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671384&group_id=5470


From noreply@sourceforge.net  Mon Jan 20 23:08:55 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 20 Jan 2003 15:08:55 -0800
Subject: [Patches] [ python-Patches-671454 ] Optimize dictionary resizing
Message-ID: <E18al2F-0003sG-00@sc8-sf-web2.sourceforge.net>

Patches item #671454, was opened at 2003-01-20 18:08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671454&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Optimize dictionary resizing

Initial Comment:
Revisiting Oren’s fastnames patch, I think a simpler 
approach is warranted.  Using a setitem macro skips 
a function call but doesn’t get to the root of problem.  
Likewise, a pointer search is not helpful because 
lookupstring() already attempts a pointer 
comparison first and a hash comparison as a 
fallback (also, a pointer search fails to find non-
interned comparisons). There is more promise in 
optimizing the search/fail/fallback sequence of 
looking for locals, globals, and builtins, but the 
approach of using custom look-ups and having 
negative entries is too invasive.

The real issue is that the dictionaries are too full.  
Whenever, it hits 2/3’s full, a resize is triggered which 
doubles the size of the dictionary, still leaving it 
relatively full and relatively close to the next 
(expensive) resize operation.

This patch makes the setitem resize operation 
quadruple the size of the dictionary.  This leads to 
fewer total resize operations and leaves the dictionary 
more sparsely populated (not only leading to fewer 
collisions, but allowing immediate detection of NOT IN 
without doing *any* comparisons of pointers or 
hashcodes).

The patch is minimally invasive.  It is only one line!  
However, is does change the order of dictionaries, so 
doctest style test code will sense the change 
immediately.

Four timing suites are attached.  Two, directly 
measure speed-ups for accessing globals and 
__builtins__.  The other two are real world apps 
which tap into all facets of python including 
subclassing, lambdas and functionals, large and 
small dicts, a wide array of data structures, heavy 
processing of strings, tuples, and numbers.   Each of 
the suites shows improvements ranging from 5% to 
25%.  PyStone also shows a marginal improvement 
which is surprising because it is dominated by fast 
locals.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671454&group_id=5470


From noreply@sourceforge.net  Mon Jan 20 23:13:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 20 Jan 2003 15:13:41 -0800
Subject: [Patches] [ python-Patches-671454 ] Optimize dictionary resizing
Message-ID: <E18al6r-00041P-00@sc8-sf-web2.sourceforge.net>

Patches item #671454, was opened at 2003-01-20 18:08
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671454&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Optimize dictionary resizing

Initial Comment:
Revisiting Oren’s fastnames patch, I think a simpler 
approach is warranted.  Using a setitem macro skips 
a function call but doesn’t get to the root of problem.  
Likewise, a pointer search is not helpful because 
lookupstring() already attempts a pointer 
comparison first and a hash comparison as a 
fallback (also, a pointer search fails to find non-
interned comparisons). There is more promise in 
optimizing the search/fail/fallback sequence of 
looking for locals, globals, and builtins, but the 
approach of using custom look-ups and having 
negative entries is too invasive.

The real issue is that the dictionaries are too full.  
Whenever, it hits 2/3’s full, a resize is triggered which 
doubles the size of the dictionary, still leaving it 
relatively full and relatively close to the next 
(expensive) resize operation.

This patch makes the setitem resize operation 
quadruple the size of the dictionary.  This leads to 
fewer total resize operations and leaves the dictionary 
more sparsely populated (not only leading to fewer 
collisions, but allowing immediate detection of NOT IN 
without doing *any* comparisons of pointers or 
hashcodes).

The patch is minimally invasive.  It is only one line!  
However, is does change the order of dictionaries, so 
doctest style test code will sense the change 
immediately.

Four timing suites are attached.  Two, directly 
measure speed-ups for accessing globals and 
__builtins__.  The other two are real world apps 
which tap into all facets of python including 
subclassing, lambdas and functionals, large and 
small dicts, a wide array of data structures, heavy 
processing of strings, tuples, and numbers.   Each of 
the suites shows improvements ranging from 5% to 
25%.  PyStone also shows a marginal improvement 
which is surprising because it is dominated by fast 
locals.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671454&group_id=5470


From noreply@sourceforge.net  Mon Jan 20 23:22:25 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 20 Jan 2003 15:22:25 -0800
Subject: [Patches] [ python-Patches-671459 ] Py_NewInterpreter missing new import hooks
Message-ID: <E18alFJ-0004KN-00@sc8-sf-web2.sourceforge.net>

Patches item #671459, was opened at 2003-01-20 15:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671459&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Josh Hoyt (joshhoyt)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_NewInterpreter missing new import hooks

Initial Comment:
Py_NewInterpreter does not add meta_path to the sys
module, causing find_module to fail. The symptom is the
failure of importing the site module in the new
interpreter. Calling _PyImportHooks_Init sets up the
sys module for this interpreter to have the proper
attributes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671459&group_id=5470


From noreply@sourceforge.net  Tue Jan 21 08:36:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 00:36:30 -0800
Subject: [Patches] [ python-Patches-671666 ] Make the default encoding provided on Windows
Message-ID: <E18attW-0003Zx-00@sc8-sf-web4.sourceforge.net>

Patches item #671666, was opened at 2003-01-21 17:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671666&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: SUZUKI Hisao (suzuki_hisao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make the default encoding provided on Windows

Initial Comment:
On Windows, some default encodings are not
provided by Python (e.g. "cp932" in Japanese
locale), while they are always available as "mbcs"
in each locale.  This patch ensures them usable in
a very efficient way by aliasing them to "mbcs" in
such a case.

Note that IDLE does not start up on Windows unless
the default encoding is provided.  The patch makes
IDLE operable all over the (Windows) world ;-).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671666&group_id=5470


From noreply@sourceforge.net  Tue Jan 21 19:24:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 11:24:11 -0800
Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory
Message-ID: <E18b40J-0005MR-00@sc8-sf-web3.sourceforge.net>

Patches item #661796, was opened at 2003-01-03 14:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: BZ2File leaking fd and memory

Initial Comment:
The attached patch fixes BZ2File() leaking the fd and
PyFileObject* info (name, read ahead buffer) when an
object is deleted.

I'm not sure the patch fixes these problems in the best
way.  It exposes most of the implementation from
fileobject.c::file_dealloc() through a private API
_PyFile_Dealloc().
BZ2File derives from PyFileObject.

Make sure the file: 'empty' exists and do: 

  from bz2 import *

A simple test which demonstrates the problem is:

  for i in range(100000): o = BZ2File('empty') ; del o

Without the patch, you quickly get:

IOError: [Errno 24] Too many open files: 'empty'

You can modify this to:

  for i in range(100000): o = BZ2File('empty') ;
o.close() ; del o

Now you can see the memory leaks.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-21 14:24

Message:
Logged In: YES 
user_id=6380

FileObject sharing: I see.  But I still think it's a bad
idea, and you're better off using stdio methods directly (as
the evolution of the FileObject implementation has already
shown).

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-01-20 15:44

Message:
Logged In: YES 
user_id=7887

Sorry about the delay. I was on a not-so-short vacation.

nnorwitz:

Thanks for the patch. I'll check the problem (for my own
understanding) and most certainly apply it.

gvanrossum:

BZ2File used to share a lot of code with FileObject.
Unfortunately (for the BZ2File side), FileObject changed
considerably post 2.2, and some of the code had to be moved
to BZ2File itself. It still
uses some code from FileObject, though (open, close, seek,
part of the softspace handling, access to attributes and
some common methods).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-05 16:11

Message:
Logged In: YES 
user_id=6380

Um, I don't understand why the BZ2File class inherits from
FileObject. It doesn't seem to be inheriting any code, and
there's no reason to inherit from FileObject just to make a
file-like object. Maybe it was a misunderstanding?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-05 15:09

Message:
Logged In: YES 
user_id=33168

I've found a better solution: change the last line of
BZ2File_dealloc() from: 
  ((PyObject*)self)->ob_type->tp_free((PyObject *)self);

to
  PyFile_Type.tp_dealloc((PyObject *)self);
Updated patch attached.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 14:48

Message:
Logged In: YES 
user_id=21627

Assigning to the author of the module for review. Gustavo,
if you can't find the time for a review, feel free to
unassign it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470


From noreply@sourceforge.net  Tue Jan 21 21:07:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 13:07:57 -0800
Subject: [Patches] [ python-Patches-670390 ] Patched test harness for logging
Message-ID: <E18b5cj-0002PQ-00@sc8-sf-web1.sourceforge.net>

Patches item #670390, was opened at 2003-01-18 14:32
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670390&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Vinay Sajip (vsajip)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patched test harness for logging

Initial Comment:
I've attached test_logging.zip which contains a new 
version of test_logging.py as well as a new version of 
the output file (test_logging).

This moves the closing of a stream till after all the 
threads have completed.

Tested under ActivePython 2.1.1 build 212 under WinXP 
Home, the script now runs correctly both when run from 
the command line and when run under regrtest.

The script uses threads and so imports threading at the 
top. The script was causing a hang *only* when run via 
regrtest or the Python command prompt if run using 
import; I tracked the problem down to the 
ThreadingMixin's process_request method. When I 
copied this into the body of my derived class, it still 
failed; but commenting out the line "import threading" 
solved the problem, at least under WinXP 
Home/ActivePython 2.1.1 build 212. Can anyone shed 
any light on this?


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-21 16:07

Message:
Logged In: YES 
user_id=6380

OK, checked in.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2003-01-18 19:27

Message:
Logged In: YES 
user_id=308438

Aaarrrgh! Sorry about the missing upload. Here it is 
(hopefully)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-18 17:43

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670390&group_id=5470


From noreply@sourceforge.net  Tue Jan 21 21:11:58 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 13:11:58 -0800
Subject: [Patches] [ python-Patches-672053 ] Py_Main() removal of exit() calls. Return value instead
Message-ID: <E18b5gc-0004OY-00@sc8-sf-web2.sourceforge.net>

Patches item #672053, was opened at 2003-01-21 16:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672053&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Douglas Napoleone (derivin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_Main() removal of exit() calls. Return value instead

Initial Comment:
Py_Main() does not perform to spec.
The C/API documentation notes that the function will 
return a value of 2 for imporper commandline values.
Instead it calls exit()

calling exit() in general is bad. The caller should be the 
one to call exit or return from main() with the supplied 
exit code.

this is particularly troublesome when there are end 
cleanup calls that need to be made before terminating 
the program and static destruction is not an option.

The patch just replaces the exit calls with a return.
Calls to usage() have their return value returned.

very streight forward



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672053&group_id=5470


From noreply@sourceforge.net  Tue Jan 21 21:38:12 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 13:38:12 -0800
Subject: [Patches] [ python-Patches-636005 ] Filter unicode into unicode
Message-ID: <E18b660-0003up-00@sc8-sf-web1.sourceforge.net>

Patches item #636005, was opened at 2002-11-09 21:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=636005&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Filter unicode into unicode

Initial Comment:
Currently, filter(None, "abc") gives "abc", but
filter(None, u"abc") gives [u'a', u'b', u'c']. This
patches corrects this, adding a Unicode specical case
for filter.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 22:38

Message:
Logged In: YES 
user_id=21627

Argh! I lost it, so I had to recreate. It is attached now.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-19 04:04

Message:
Logged In: YES 
user_id=80475

Do you still have this patch available?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-11-11 10:11

Message:
Logged In: YES 
user_id=38388

There's no patch attached to this SF item, but
you're right, filter() should behave in the same
way for 8-bit strings as for Unicode.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=636005&group_id=5470


From noreply@sourceforge.net  Tue Jan 21 22:04:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 14:04:29 -0800
Subject: [Patches] [ python-Patches-671666 ] Make the default encoding provided on Windows
Message-ID: <E18b6VR-0004v7-00@sc8-sf-web3.sourceforge.net>

Patches item #671666, was opened at 2003-01-21 09:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671666&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: SUZUKI Hisao (suzuki_hisao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make the default encoding provided on Windows

Initial Comment:
On Windows, some default encodings are not
provided by Python (e.g. "cp932" in Japanese
locale), while they are always available as "mbcs"
in each locale.  This patch ensures them usable in
a very efficient way by aliasing them to "mbcs" in
such a case.

Note that IDLE does not start up on Windows unless
the default encoding is provided.  The patch makes
IDLE operable all over the (Windows) world ;-).

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 23:04

Message:
Logged In: YES 
user_id=21627

I'm rejecting this patch. The factory system default
encoding of Python is ASCII, on all platforms (atleast, it
should be this way; MacOS currently deviates).

I cannot reproduce the IDLE problem; IDLE starts without
that patch just fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671666&group_id=5470


From noreply@sourceforge.net  Tue Jan 21 22:08:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 14:08:39 -0800
Subject: [Patches] [ python-Patches-671459 ] Py_NewInterpreter missing new import hooks
Message-ID: <E18b6ZT-0005Ei-00@sc8-sf-web4.sourceforge.net>

Patches item #671459, was opened at 2003-01-21 00:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671459&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Josh Hoyt (joshhoyt)
>Assigned to: Just van Rossum (jvr)
Summary: Py_NewInterpreter missing new import hooks

Initial Comment:
Py_NewInterpreter does not add meta_path to the sys
module, causing find_module to fail. The symptom is the
failure of importing the site module in the new
interpreter. Calling _PyImportHooks_Init sets up the
sys module for this interpreter to have the proper
attributes.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 23:08

Message:
Logged In: YES 
user_id=21627

This patch looks quite right to me. Just, any objections?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671459&group_id=5470


From noreply@sourceforge.net  Tue Jan 21 22:10:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 14:10:33 -0800
Subject: [Patches] [ python-Patches-636005 ] Filter unicode into unicode
Message-ID: <E18b6bJ-0005Ku-00@sc8-sf-web4.sourceforge.net>

Patches item #636005, was opened at 2002-11-09 15:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=636005&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Filter unicode into unicode

Initial Comment:
Currently, filter(None, "abc") gives "abc", but
filter(None, u"abc") gives [u'a', u'b', u'c']. This
patches corrects this, adding a Unicode specical case
for filter.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 16:38

Message:
Logged In: YES 
user_id=21627

Argh! I lost it, so I had to recreate. It is attached now.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 22:04

Message:
Logged In: YES 
user_id=80475

Do you still have this patch available?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-11-11 04:11

Message:
Logged In: YES 
user_id=38388

There's no patch attached to this SF item, but
you're right, filter() should behave in the same
way for 8-bit strings as for Unicode.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=636005&group_id=5470


From noreply@sourceforge.net  Tue Jan 21 22:27:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 14:27:01 -0800
Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv
Message-ID: <E18b6rF-000630-00@sc8-sf-web3.sourceforge.net>

Patches item #670715, was opened at 2003-01-19 17:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
>Assigned to: Martin v. Löwis (loewis)
Summary: Universal Unicode Codec for POSIX iconv

Initial Comment:
Here's the unicode codec using POSIX iconv(3) library.

Tested on these platforms and seems to work:
  FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64,
  FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2

This codec implementation supports PEP293, also.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 23:27

Message:
Logged In: YES 
user_id=21627

I'm quite happy with this patch, and will apply it shortly.
However, I am concerned that it is specific for GNU iconv.
IMO, there should be machinery to find out the "internal"
encoding, in case native the native iconv implementation is
used instead of GNU iconv.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-20 14:33

Message:
Logged In: YES 
user_id=55188

Thank you for comments. :->
I uploaded a new revised patch with unittest and some code
style fixes.

I saw Martin v. Loewis's iconvcodecs about a years ago.
His implementation is very neat, but it had a limit on error
handling due to recursive call.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-19 23:56

Message:
Logged In: YES 
user_id=38388

The patch looks good, but you'll need to add some form
of testing to underline the "seems to work" :-)

Some docs on how to use the codec would also be needed.

Martin von Loewis has written a similar codec some months ago.
Perhaps you two could get in touch and sort out the details ?!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470


From noreply@sourceforge.net  Tue Jan 21 22:40:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 14:40:48 -0800
Subject: [Patches] [ python-Patches-671459 ] Py_NewInterpreter missing new import hooks
Message-ID: <E18b74a-0006aZ-00@sc8-sf-web4.sourceforge.net>

Patches item #671459, was opened at 2003-01-21 00:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671459&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Josh Hoyt (joshhoyt)
Assigned to: Just van Rossum (jvr)
Summary: Py_NewInterpreter missing new import hooks

Initial Comment:
Py_NewInterpreter does not add meta_path to the sys
module, causing find_module to fail. The symptom is the
failure of importing the site module in the new
interpreter. Calling _PyImportHooks_Init sets up the
sys module for this interpreter to have the proper
attributes.

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2003-01-21 23:40

Message:
Logged In: YES 
user_id=92689

No, looks fine to me. Can you check it in?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 23:08

Message:
Logged In: YES 
user_id=21627

This patch looks quite right to me. Just, any objections?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671459&group_id=5470


From noreply@sourceforge.net  Tue Jan 21 22:54:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 14:54:53 -0800
Subject: [Patches] [ python-Patches-671459 ] Py_NewInterpreter missing new import hooks
Message-ID: <E18b7ID-0000dg-00@sc8-sf-web2.sourceforge.net>

Patches item #671459, was opened at 2003-01-21 00:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671459&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Josh Hoyt (joshhoyt)
>Assigned to: Martin v. Löwis (loewis)
Summary: Py_NewInterpreter missing new import hooks

Initial Comment:
Py_NewInterpreter does not add meta_path to the sys
module, causing find_module to fail. The symptom is the
failure of importing the site module in the new
interpreter. Calling _PyImportHooks_Init sets up the
sys module for this interpreter to have the proper
attributes.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-01-21 23:40

Message:
Logged In: YES 
user_id=92689

No, looks fine to me. Can you check it in?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 23:08

Message:
Logged In: YES 
user_id=21627

This patch looks quite right to me. Just, any objections?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671459&group_id=5470


From noreply@sourceforge.net  Wed Jan 22 00:21:45 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 16:21:45 -0800
Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv
Message-ID: <E18b8eH-0002FZ-00@sc8-sf-web1.sourceforge.net>

Patches item #670715, was opened at 2003-01-20 01:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Martin v. Löwis (loewis)
Summary: Universal Unicode Codec for POSIX iconv

Initial Comment:
Here's the unicode codec using POSIX iconv(3) library.

Tested on these platforms and seems to work:
  FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64,
  FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2

This codec implementation supports PEP293, also.


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2003-01-22 09:21

Message:
Logged In: YES 
user_id=55188

iconv implementations on commercial UNIXes are very scary. 

Solaris implementation:
  no support for CJK <-> UCS conversion.
  They support UCS[24] only for iso-8859 and UTFs.

HP-UX implementation:
  They have useless iconv. HP-UX iconv has no unicode support.

BSD implementation (Konstantin Chuguev's):
  compatible with this patch (provides ucs-[24]-internal)

GLIBC implementation:
  provides ucs-[24] and they are same with GNU iconv's
ucs-[24]-internal.
  Because ucs-[24] of GNU/BSD implentation is big endian
always. We can't use ucs-[24] for every platform.

In conclusion, we must use 3rd party iconv on Solaris or HP-UX.
And, we need to detect whether the linked iconv is GNU/BSD
iconv or GLIBC iconv. (how?)

I'll investigate how to detect them, but ... :)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 07:27

Message:
Logged In: YES 
user_id=21627

I'm quite happy with this patch, and will apply it shortly.
However, I am concerned that it is specific for GNU iconv.
IMO, there should be machinery to find out the "internal"
encoding, in case native the native iconv implementation is
used instead of GNU iconv.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-20 22:33

Message:
Logged In: YES 
user_id=55188

Thank you for comments. :->
I uploaded a new revised patch with unittest and some code
style fixes.

I saw Martin v. Loewis's iconvcodecs about a years ago.
His implementation is very neat, but it had a limit on error
handling due to recursive call.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-20 07:56

Message:
Logged In: YES 
user_id=38388

The patch looks good, but you'll need to add some form
of testing to underline the "seems to work" :-)

Some docs on how to use the codec would also be needed.

Martin von Loewis has written a similar codec some months ago.
Perhaps you two could get in touch and sort out the details ?!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470


From noreply@sourceforge.net  Wed Jan 22 01:07:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 21 Jan 2003 17:07:47 -0800
Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv
Message-ID: <E18b9Mp-0005zZ-00@sc8-sf-web2.sourceforge.net>

Patches item #670715, was opened at 2003-01-19 17:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Martin v. Löwis (loewis)
Summary: Universal Unicode Codec for POSIX iconv

Initial Comment:
Here's the unicode codec using POSIX iconv(3) library.

Tested on these platforms and seems to work:
  FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64,
  FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2

This codec implementation supports PEP293, also.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 02:07

Message:
Logged In: YES 
user_id=21627

Hmm. I see that Solaris does support conversion of CJK to
UTF-8. So even though we cannot convert into the internal
encoding, we could still convert through UTF-8.

Looking at /usr/lib/nls/iconv/config.iconv of HP-UX 11.11, I
see conversions from and to ucs2, for iso-8859, eucJP, sjis,
eucTW, big5, roc15, kore5, hp15CN, and many IBM code pages.

So I think the iconv codec should convert into the Python
internal representation if possible. If no encoding name for
that is known, it should convert to ucs2 (be) if possible,
or else to UTF-8; in all cases, it will then construct a
Unicode object from the resulting string.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-22 01:21

Message:
Logged In: YES 
user_id=55188

iconv implementations on commercial UNIXes are very scary. 

Solaris implementation:
  no support for CJK <-> UCS conversion.
  They support UCS[24] only for iso-8859 and UTFs.

HP-UX implementation:
  They have useless iconv. HP-UX iconv has no unicode support.

BSD implementation (Konstantin Chuguev's):
  compatible with this patch (provides ucs-[24]-internal)

GLIBC implementation:
  provides ucs-[24] and they are same with GNU iconv's
ucs-[24]-internal.
  Because ucs-[24] of GNU/BSD implentation is big endian
always. We can't use ucs-[24] for every platform.

In conclusion, we must use 3rd party iconv on Solaris or HP-UX.
And, we need to detect whether the linked iconv is GNU/BSD
iconv or GLIBC iconv. (how?)

I'll investigate how to detect them, but ... :)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 23:27

Message:
Logged In: YES 
user_id=21627

I'm quite happy with this patch, and will apply it shortly.
However, I am concerned that it is specific for GNU iconv.
IMO, there should be machinery to find out the "internal"
encoding, in case native the native iconv implementation is
used instead of GNU iconv.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-20 14:33

Message:
Logged In: YES 
user_id=55188

Thank you for comments. :->
I uploaded a new revised patch with unittest and some code
style fixes.

I saw Martin v. Loewis's iconvcodecs about a years ago.
His implementation is very neat, but it had a limit on error
handling due to recursive call.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-19 23:56

Message:
Logged In: YES 
user_id=38388

The patch looks good, but you'll need to add some form
of testing to underline the "seems to work" :-)

Some docs on how to use the codec would also be needed.

Martin von Loewis has written a similar codec some months ago.
Perhaps you two could get in touch and sort out the details ?!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470


From noreply@sourceforge.net  Wed Jan 22 09:04:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 22 Jan 2003 01:04:52 -0800
Subject: [Patches] [ python-Patches-671459 ] Py_NewInterpreter missing new import hooks
Message-ID: <E18bGoW-0008QF-00@sc8-sf-web3.sourceforge.net>

Patches item #671459, was opened at 2003-01-21 00:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671459&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Josh Hoyt (joshhoyt)
Assigned to: Martin v. Löwis (loewis)
Summary: Py_NewInterpreter missing new import hooks

Initial Comment:
Py_NewInterpreter does not add meta_path to the sys
module, causing find_module to fail. The symptom is the
failure of importing the site module in the new
interpreter. Calling _PyImportHooks_Init sets up the
sys module for this interpreter to have the proper
attributes.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 10:04

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Fixed in pythonrun.c 2.175.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-01-21 23:40

Message:
Logged In: YES 
user_id=92689

No, looks fine to me. Can you check it in?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 23:08

Message:
Logged In: YES 
user_id=21627

This patch looks quite right to me. Just, any objections?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671459&group_id=5470


From Grow_Youngersuyi@desertmail.com  Wed Jan 22 22:26:52 2003
From: Grow_Youngersuyi@desertmail.com (Yes)
Date: Wed, 22 Jan 2003 18:26:52 -0400
Subject: [Patches] Thank You For Your Interest: Medical News
Message-ID: <001501d1ba34$aeb31142$20685167@apdmgnw.psg>

------=_NextPart_000_00B1_66C71C2D.A1723E58
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64


S25vdyB0aGUgZGlmZmVyZW50IEhHSCBwcm9kdWN0cw0KDQo8aHRtbD4NCg0K
PGhlYWQ+DQoNCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29u
dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQoNCjxt
ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTWljcm9zb2Z0IEZyb250
UGFnZSA0LjAiPg0KDQo8bWV0YSBuYW1lPSJQcm9nSWQiIGNvbnRlbnQ9IkZy
b250UGFnZS5FZGl0b3IuRG9jdW1lbnQiPg0KDQo8dGl0bGU+VGhlcmUgYXJl
IHRocmVlIGRpZmZlcmVudCB0eXBlcyBvZiBIR0ggcHJvZHVjdHM8L3RpdGxl
Pg0KDQo8L2hlYWQ+DQoNCjxib2R5IGJhY2tncm91bmQ9ImNsb3Vkcy5qcGci
Pg0KDQo8cD48Zm9udCBzaXplPSI0Ij48Zm9udCBjb2xvcj0iIzgwMDAwMCI+
PGI+VGhlcmUgYXJlIHRocmVlIGRpZmZlcmVudCB0eXBlcyBvZg0KDQpIR0gg
cHJvZHVjdHMuPC9iPjwvZm9udD48YnI+DQoNClRoZSBjb25mdXNpb24gaXMg
dGhhdCBhbGwgdGhyZWUgYXJlPGJyPg0KDQphZHZlcnRpc2VkIGFzIGlmIHRo
ZXkgd2VyZSB0aGUgc2FtZS48L2ZvbnQ+PGJyPg0KDQombmJzcDs8YnI+DQoN
CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8
dT5UaGUgdGhyZWUgdHlwZXMgYXJlOjwvdT48YnI+DQoNCiZuYnNwOzxicj4N
Cg0KPGI+MSk8L2I+IC0tLSA8Zm9udCBjb2xvcj0iIzAwMDBGRiI+PGI+SG9t
ZW9wYXRoaWMgSEdIPC9iPjwvZm9udD48YnI+DQoNCjxiPjIpPC9iPiAtLS0g
PGZvbnQgY29sb3I9IiMwMDAwRkYiPjxiPlByZS1jdXJzb3IgSEdIPC9iPjwv
Zm9udD48YnI+DQoNCjxiPjMpPC9iPiAtLS0gPGZvbnQgY29sb3I9IiMwMDAw
RkYiPjxiPlJlYWwgb3Igc3ludGhldGljIEhHSDwvYj48L2ZvbnQ+DQoNCihk
ZWxpdmVyZWQgYnkgaW5qZWN0aW9uPGJyPg0KDQombmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3IsIGJ5IGFuIG9yYWwgc3By
YXkgbWV0aG9kKS48YnI+DQoNCiZuYnNwOzxicj4NCg0KRG8geW91IGtub3cg
ZGlmZmVyZW5jZXM/PGJyPg0KDQombmJzcDs8YnI+DQoNCkNhbGwgdXMgYW5k
IHdlJ2xsIGV4cGxhaW4gdGhlbSB0byB5b3UuPGJyPg0KDQombmJzcDs8YnI+
DQoNCk91ciB0b2xsIGZyZWUgbnVtYmVyIGlzIDxmb250IGNvbG9yPSIjMDAw
MDgwIj48Yj4xLTg4OC02MjEtNzMwMDwvYj48L2ZvbnQ+PGJyPg0KDQpBbiBI
R0ggc3RhZmYgbWVtYmVyIGlzIGF2YWlsYWJsZTxicj4NCg0KOSB0byA1IFBh
Y2lmaWMgVGltZS48YnI+DQoNCklmIGFmdGVyIGhvdXJzLCBwbGVhc2UgbGVh
dmUgeW91IG5hbWU8YnI+DQoNCmFuZCBkYXkgYW5kIGV2ZW5pbmcgcGhvbmUg
bnVtYmVycy48YnI+DQoNCldlIHdpbGwgY2FsbCB5b3UgYmFjayBpbiBhIG5v
IHByZXNzdXJlLDxicj4NCg0KZWR1Y2F0aW9uYWwgbWFubmVyLjxicj4NCg0K
SWYgeW91IGFyZSBvdmVyc2VhcyBjYWxsIHlvdXIgbG9uZyBkaXN0YW5jZTxi
cj4NCg0Kb3BlcmF0b3IgYW5kIGFzayB0byBiZSBjb25uZWN0ZWQgdG8gb3Vy
PGJyPg0KDQpwaG9uZSBudW1iZXIuJm5ic3A7IFdlIHdpbGwgY2FsbCB5b3Ug
YmFjayBzbzxicj4NCg0Kd2UgY2FuIHBheSBmb3IgdGhlIGxvbmcgZGlzdGFu
Y2UgY2hhcmdlcy48YnI+DQoNCiZuYnNwOzxicj4NCg0KPGZvbnQgY29sb3I9
IiNGRjAwMDAiPkZvciBtb3JlIGluZm9ybWF0aW9uIG9uIEhHSCByZWFkIG9u
Li4uLi4uLi4uLi4uPC9mb250Pjxicj4NCg0KJm5ic3A7PGJyPg0KDQpIQVZF
IFlPVSBIRUFSRCBPRjxicj4NCg0KSFVNQU4gR1JPV1RIIEhPUk1PTkUgKEhH
SCk/Pz88YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IFJlbGVhc2VkIGJ5IHlvdXIgb3duIHBpdHVpdGFyeSBnbGFuZCwg
SEdIIHN0YXJ0cw0KDQpkZWNsaW5pbmc8YnI+DQoNCmluIHlvdXIgMjBzLCBl
dmVuIG1vcmUgaW4geW91ciAzMHMgYW5kIDQwcywgZXZlbnR1YWxseSByZXN1
bHRpbmc8YnI+DQoNCmluIHRoZSBzaHJpbmthZ2Ugb2YgbWFqb3Igb3JnYW5z
IC0tIHBsdXMsIGFsbDxicj4NCg0Kb3RoZXIgc3ltcHRvbXMgcmVsYXRlZCB0
byBvbGQgYWdlLjxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDs8YnI+DQoN
CklOIFRIT1VTQU5EUyBPRiBDTElOSUNBTCBTVFVESUVTLDxicj4NCg0KSEdI
IEhBUyBCRUVOIFNIT1dOIFRPIEFDQ09NUExJU0ggVEhFIEZPTExPV0lORzo8
YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBSZWR1Y2UgQm9keSBGYXQgYW5kIEJ1
aWxkIExlYW4gTXVzY2xlPGJyPg0KDQombmJzcDsmbmJzcDsgV0lUSE9VVCBF
WEVSQ0lTRSE8YnI+DQoNCiZuYnNwOzxicj4NCg0KKiBFbmhhbmNlIFNleHVh
bCBQZXJmb3JtYW5jZTxicj4NCg0KJm5ic3A7PGJyPg0KDQoqIFJlbW92ZSBX
cmlua2xlcyBhbmQgQ2VsbHVsaXRlPGJyPg0KDQombmJzcDs8YnI+DQoNCiog
TG93ZXIgQmxvb2QgUHJlc3N1cmUgYW5kIEltcHJvdmUgQ2hvbGVzdGVyb2wg
UHJvZmlsZTxicj4NCg0KJm5ic3A7PGJyPg0KDQoqIEltcHJvdmUgU2xlZXAs
IFZpc2lvbiBhbmQgTWVtb3J5PGJyPg0KDQombmJzcDs8YnI+DQoNCiogUmVz
dG9yZSBIYWlyIENvbG9yIGFuZCBHcm93dGg8YnI+DQoNCiZuYnNwOzxicj4N
Cg0KKiBTdHJlbmd0aGVuIHRoZSBJbW11bmUgU3lzdGVtPGJyPg0KDQombmJz
cDs8YnI+DQoNCiogSW5jcmVhc2UgRW5lcmd5IGFuZCBDYXJkaWFjIE91dHB1
dDxicj4NCg0KJm5ic3A7PGJyPg0KDQoqIFR1cm4gYmFjayB5b3VyIGJvZHkn
cyBCaW9sb2dpY2FsIFRpbWUgQ2xvY2sgMTAgLSAyMCB5ZWFyczxicj4NCg0K
Jm5ic3A7PGJyPg0KDQoqIExpdmUgTG9uZ2VyIEFORCBTdHJvbmdlcjxicj4N
Cg0KJm5ic3A7PGJyPg0KDQpBbGwgbmF0dXJhbCBhbmQgb3JnYW5pYyBwbGFu
dCBiYXNlZDxicj4NCg0KJm5ic3A7PGJyPg0KDQo8Zm9udCBjb2xvcj0iIzAw
MDBGRiI+PGI+RkVFTCAxMCBZRUFSUyBZT1VOR0VSIFdJVEggT1JBTCBTUFJB
WSBIR0guPGJyPg0KDQpHVUFSQU5URUVEPC9iPjwvZm9udD48YnI+DQoNCiZu
YnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFdlIGFyZSB0aGUgbWFu
dWZhY3R1cmVyIGFuZCB3ZSBzZWxsIGRpcmVjdGx5IHRvIERvY3RvcnMsPGJy
Pg0KDQpDaGlyb3ByYWN0b3JzLCBhbmQgY29uc3VtZXJzIHdvcmxkIHdpZGUg
dGhlIGhpZ2hlc3QgZ3JhZGU8YnI+DQoNCiZuYnNwO0hHSCBPcmFsIFNwcmF5
IGF2YWlsYWJsZS4mbmJzcDs8YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdpdGggaW50ZXJuZXQgbWFya2V0aW5nLCB3
ZSBhcmUgYWJsZSB0byBzYXZlDQoNCmFkdmVydGlzaW5nPGJyPg0KDQpjb3N0
IGFuZCBwYXNzIHRob3NlIHNhdmluZ3MgYWxvbmcgdG8geW91Ljxicj4NCg0K
QnV0IHlvdSBtdXN0IGFjdCBub3cuJm5ic3A7PGJyPg0KDQombmJzcDs8YnI+
DQoNClRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBjYWxsJm5ic3A7IHVz
IG5vdy48YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IFRPTEwgRlJFRSA8Yj48Zm9udCBjb2xvcj0iIzAwMDA4MCI+MS04ODgt
NjIxLTczMDA8L2ZvbnQ+PC9iPjxicj4NCg0KJm5ic3A7PGJyPg0KDQpXZSBt
dXN0IHNwZWFrIHRvIHlvdSBpbiBwZXJzb24gdG8gcXVhbGlmeSB5b3VyIHVz
YWdlLjxicj4NCg0KJm5ic3A7PGJyPg0KDQombmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgQWxsIG9mIHlvdXIgcXVlc3Rpb25zIHdpbGwgYmUgYWRkcmVzc2Vk
IGFuZCBhbnN3ZXJlZCBpbg0KDQphIGZyaWVuZGx5LDxicj4NCg0Kbm8gcHJl
c3N1cmUgbWFubmVyLiZuYnNwOyBPdXIgbWFpbiBwdXJwb3NlIGlzIHRvIHBy
b3ZpZGUgeW91IHdpdGg8YnI+DQoNCiZuYnNwO2luZm9ybWF0aW9uIHNvIHlv
dSBjYW4gbWFrZSBhbiBlZHVjYXRlZCBkZWNpc2lvbi48YnI+DQoNCiZuYnNw
Ozxicj4NCg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZvciBtb3JlIGlu
Zm9ybWF0aW9uIGNhbGw8YnI+DQoNCiZuYnNwOzxicj4NCg0KJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IDxiPjxmb250IGNvbG9yPSIjMDAwMDgwIj4xLTg4OC02
MjEtNzMwMDwvZm9udD48L2I+PGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNw
O0lmIHlvdSBhcmUgb24gbGluZSB3cml0ZSBkb3duIG91cjxicj4NCg0KcGhv
bmUgbnVtYmVyIGFuZCBjYWxsIHVzIHdoZW4geW91IGNhbi48YnI+DQoNCiZu
YnNwOzxicj4NCg0KU29vbiwgeW91IGFuZCB5b3VyIGxvdmVkIG9uZXMgd2ls
bCBiZSB2ZXJ5IGdsYWQgeW91IGRpZC48YnI+DQoNCiZuYnNwOzxicj4NCg0K
UmVhZCB3aGF0IHBlb3BsZSBhcmUgc2F5aW5nOjxicj4NCg0KJm5ic3A7PGJy
Pg0KDQomcXVvdDtUaGUgZWZmZWN0cyBvZiA2IG1vbnRocyBvZiBHSCBvbjxi
cj4NCg0KbGVhbiBib2R5IG1hc3MgYW5kIGZhdCB3ZXJlIGVxdWl2YWxlbnQ8
YnI+DQoNCmluIG1hZ25pdHVkZSB0byB0aGUgY2hhbmdlcyBpbmN1cnJlZDxi
cj4NCg0KZHVyaW5nIDEwLTIwIHllYXJzIG9mIGFnaW5nLiZxdW90Ozxicj4N
Cg0KRHIuIERhbmllbCBSdWRtYW4sIE1ELDxicj4NCg0KTmV3IEVuZ2xhbmQg
Sm91cm5hbCBvZiBNZWRpY2luZS48YnI+DQoNCiZuYnNwOzxicj4NCg0KJnF1
b3Q7V2l0aGluIGZvdXIgbW9udGhzLCBteSBib2R5IGZhdCBkZWNyZWFzZWQ8
YnI+DQoNCiZuYnNwO2Zvcm0gMzAlIGRvd24gdG8gMjElISBJIG5vdGljZWQg
bXkgc2tpbjxicj4NCg0KJm5ic3A7aXMgbW9yZSBzdXBwbGUgYW5kIG15IG92
ZXJhbGwgbWVudGFsPGJyPg0KDQombmJzcDtvdXRsb29rIGltcHJvdmVkIHNp
Z25pZmljYW50bHkuJnF1b3Q7PGJyPg0KDQombmJzcDtELlcuLCBOZXcgSmVy
c2V5PGJyPg0KDQombmJzcDs8YnI+DQoNCiZxdW90O1dlIGhhdmUgYmVlbiBv
biB0aGUgc3ByYXkgZm9yIGp1c3QgMyB3ZWVrczxicj4NCg0Kbm93LCBhbmQg
YmVzaWRlcyB0aGUgdHJlbWVuZG91cyBlbmVyZ3kgd2U8YnI+DQoNCmJvdGgg
ZmVlbCwgbXkgaHVzYmFuZHMgYWxsZXJnaWVzIGFuZCBzcGVsbHM8YnI+DQoN
Cm9mIGRlcHJlc3Npb24gaGF2ZSBsaWZ0ZWQuIEkgYW0gaGVhbGluZzxicj4N
Cg0KZXh0cmVtZWx5IGZhc3QgYWZ0ZXIgYW4gYWNjaWRlbnQgYW5kIGhhdmU8
YnI+DQoNCmxvc3QgNyBsYnMuIHdpdGhvdXQgdHJ5aW5nISZxdW90Ozxicj4N
Cg0KQy5CLiwgRmxhZ3N0YWZmLiBBWjxicj4NCg0KJm5ic3A7PGJyPg0KDQpU
aGFua3MgZm9yIHJlYWRpbmcgb3VyIGxldHRlciw8YnI+DQoNClRoZSBIR0gg
U3RhZmY8YnI+DQoNClVTQSBEaXZpc2lvbjxicj4NCg0KJm5ic3A7PGJyPg0K
DQpQUzombmJzcDsgVGhlIEhHSCBTdGFmZiBndWFyYW50ZWVzIHRoZTxicj4N
Cg0KaGlnaGVzdCBxdWFsaXR5IGFuZCBsb3dlc3QgcHJpY2UuPGJyPg0KDQom
bmJzcDs8YnI+DQoNCiZuYnNwO1dlIG1hbnVmYWN0dXJlIGFuZCBzaGlwIGRp
cmVjdGx5IHRvIHlvdXIgZG9vci48YnI+DQoNCiZuYnNwOzxicj4NCg0KQ2Fs
bCB1cyBub3cgPGI+PGZvbnQgY29sb3I9IiMwMDAwODAiPjEtODg4LTYyMS03
MzAwPC9mb250PjwvYj48YnI+DQoNCiZuYnNwOzxicj4NCg0KPT09PT09PSZu
YnNwOyZuYnNwOyBFbmQgb2YgbWVzc2FnZSA9PT09PT09PSZuYnNwOzxicj4N
Cg0KJm5ic3A7PGJyPg0KDQombmJzcDsmbmJzcDsgVGhlIGZvbGxvd2luZyBz
dGF0ZW1lbnQgaXMgcHJvdmlkZWQgdG8gYmU8YnI+DQoNCmluIGNvbXBsaWFu
Y2Ugd2l0aCBjb21tZXJjaWFsIGVtYWlsIGxhd3MuPGJyPg0KDQombmJzcDs8
YnI+DQoNCiZuYnNwOyZuYnNwOyBJZiB5b3UgZG8gbm90IHdpc2ggdG8gcmVj
ZWl2ZSBmdXJ0aGVyPGJyPg0KDQptYWlsaW5ncywgcGxlYXNlIGNsaWNrIHJl
cGx5IHRvOiAgcGxzcmVtaGdoMzRAYnRhbWFpbC5uZXQuY24gIGFuZCB0eXBl
IHJlbW92ZSBpbiB0aGUgc3ViamVjdCBib3guPGJyPg0KDQpUaGVuIGNsaWNr
IHNlbmQuPGJyPg0KDQombmJzcDs8YnI+DQoNCiZuYnNwOyZuYnNwOyBUaGlz
IG1lc3NhZ2UgaXMgaW4gZnVsbCBjb21wbGlhbmNlIHdpdGg8YnI+DQoNClUu
Uy4gRmVkZXJhbCByZXF1aXJlbWVudHMgZm9yIGNvbW1lcmNpYWw8YnI+DQoN
CmVtYWlsIHVuZGVyIGJpbGwgUy4xNjE4IFRpdGxlIGxsbCwgU2VjdGlvbiAz
MDEsPGJyPg0KDQpQYXJhZ3JhcGggKGEpKDIpKEMpIHBhc3NlZCBieSB0aGUg
MTA1dGggVS5TLjxicj4NCg0KQ29uZ3Jlc3MgYW5kIGlzIG5vdCBjb25zaWRl
cmVkIFNQQU08YnI+DQoNCnNpbmNlIGl0IGluY2x1ZGVzIGEgcmVtb3ZlIG1l
Y2hhbmlzbS4qPGJyPg0KDQpUaGlzIG1lc3NhZ2UgaXMgbm90IGludGVuZGVk
IGZvciByZXNpZGVudHMgaW4gdGhlPGJyPg0KDQpzdGF0ZXMgb2YgQ0EsIE5D
LCBOViwgUkksIFROLCBWQSAmYW1wOyBXQS48YnI+DQoNClNjcmVlbmluZyBv
ZiBhZGRyZXNzZXMgaGFzIGJlZW4gZG9uZSB0byB0aGUgYmVzdDxicj4NCg0K
b2Ygb3VyIHRlY2huaWNhbCBhYmlsaXR5Ljxicj4NCg0KJm5ic3A7PGJyPg0K
DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FsbCB1cw0KDQpub3cg
PGI+PGZvbnQgY29sb3I9IiMwMDAwODAiPjEtODg4LTYyMS03MzAwPC9mb250
PjwvYj4gZm9yIHlvdXI8YnI+DQoNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBmcmVlDQoNCkhHSCBjb25zdWx0YXRpb24uPC9wPg0KDQo8cD48YnI+
DQoNClRoYW5rIHlvdTwvcD4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQoNCiAN
CiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiAN
CiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiAN
CiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCg0K
LS0NCg0KMjAyOU1JaGowLTM1MVJ6R1A2NDEwa0RTaDgtNzhsMjc=


From noreply@sourceforge.net  Wed Jan 22 15:29:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 22 Jan 2003 07:29:34 -0800
Subject: [Patches] [ python-Patches-559288 ] Use builtin boolean if present
Message-ID: <E18bMoo-00034Q-00@sc8-sf-web2.sourceforge.net>

Patches item #559288, was opened at 2002-05-22 12:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Martin v. Löwis (loewis)
Summary: Use builtin boolean if present

Initial Comment:
Now that Python has a boolean type, perhaps xmlrpclib 
should use it if available.  Here's a patch that (I think) 
does what's necessary.  The existing test case (which 
does manipulate a boolean) passes.  Haven't tested it 
with a pre-bool version of Python though.

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-22 09:29

Message:
Logged In: YES 
user_id=44345

Here's a new version.  I think there may still be problems related to 2.2
(see the dump_bool method), but it should be better w.r.t. 2.1 and earlier
versions.  I'd really like to see this get into 2.3.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-07 16:44

Message:
Logged In: YES 
user_id=21627

I think xmlrpclib.{True,False} must stay, even though they 
could become aliases for the builtin True and False (notice 
that you can access True with bool(1))

The module must stay 1.5.2 compatible, I think this is 
currently not the case: dispatching is based on the type, but 
type(True) will be ClassType in 1.5.2.

The test looks for True to determine presence of the boolean 
type; this is incorrect: Python 2.2 has True without having 
bool. The test also binds x without reason. I'd suggest 

try:
  boolean = bool
except:
   ...

instead

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-02 12:03

Message:
Logged In: YES 
user_id=44345

updated patch which avoids using types.BooleanType since there was so 
much pushback on the idea.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-05-22 12:46

Message:
Logged In: YES 
user_id=44345

new patch - don't know why running the test suite didn't catch
the NameError...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470


From noreply@sourceforge.net  Wed Jan 22 15:39:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 22 Jan 2003 07:39:30 -0800
Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory
Message-ID: <E18bMyQ-0003pg-00@sc8-sf-web2.sourceforge.net>

Patches item #661796, was opened at 2003-01-03 19:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: BZ2File leaking fd and memory

Initial Comment:
The attached patch fixes BZ2File() leaking the fd and
PyFileObject* info (name, read ahead buffer) when an
object is deleted.

I'm not sure the patch fixes these problems in the best
way.  It exposes most of the implementation from
fileobject.c::file_dealloc() through a private API
_PyFile_Dealloc().
BZ2File derives from PyFileObject.

Make sure the file: 'empty' exists and do: 

  from bz2 import *

A simple test which demonstrates the problem is:

  for i in range(100000): o = BZ2File('empty') ; del o

Without the patch, you quickly get:

IOError: [Errno 24] Too many open files: 'empty'

You can modify this to:

  for i in range(100000): o = BZ2File('empty') ;
o.close() ; del o

Now you can see the memory leaks.


----------------------------------------------------------------------

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-01-22 15:39

Message:
Logged In: YES 
user_id=7887

Ok. Do you want me to work on this for 2.3?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-21 19:24

Message:
Logged In: YES 
user_id=6380

FileObject sharing: I see.  But I still think it's a bad
idea, and you're better off using stdio methods directly (as
the evolution of the FileObject implementation has already
shown).

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-01-20 20:44

Message:
Logged In: YES 
user_id=7887

Sorry about the delay. I was on a not-so-short vacation.

nnorwitz:

Thanks for the patch. I'll check the problem (for my own
understanding) and most certainly apply it.

gvanrossum:

BZ2File used to share a lot of code with FileObject.
Unfortunately (for the BZ2File side), FileObject changed
considerably post 2.2, and some of the code had to be moved
to BZ2File itself. It still
uses some code from FileObject, though (open, close, seek,
part of the softspace handling, access to attributes and
some common methods).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-05 21:11

Message:
Logged In: YES 
user_id=6380

Um, I don't understand why the BZ2File class inherits from
FileObject. It doesn't seem to be inheriting any code, and
there's no reason to inherit from FileObject just to make a
file-like object. Maybe it was a misunderstanding?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-05 20:09

Message:
Logged In: YES 
user_id=33168

I've found a better solution: change the last line of
BZ2File_dealloc() from: 
  ((PyObject*)self)->ob_type->tp_free((PyObject *)self);

to
  PyFile_Type.tp_dealloc((PyObject *)self);
Updated patch attached.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 19:48

Message:
Logged In: YES 
user_id=21627

Assigning to the author of the module for review. Gustavo,
if you can't find the time for a review, feel free to
unassign it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470


From noreply@sourceforge.net  Wed Jan 22 16:09:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 22 Jan 2003 08:09:18 -0800
Subject: [Patches] [ python-Patches-559288 ] Use builtin boolean if present
Message-ID: <E18bNRG-00014z-00@sc8-sf-web3.sourceforge.net>

Patches item #559288, was opened at 2002-05-22 19:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Martin v. Löwis (loewis)
Summary: Use builtin boolean if present

Initial Comment:
Now that Python has a boolean type, perhaps xmlrpclib 
should use it if available.  Here's a patch that (I think) 
does what's necessary.  The existing test case (which 
does manipulate a boolean) passes.  Haven't tested it 
with a pre-bool version of Python though.

Skip


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 17:09

Message:
Logged In: YES 
user_id=21627

I suggest you introduce a _bool_is_builtin flag early on,
e.g. with

try:
  bla bla bla
  _bool_is_builtin = False.__class__.__name__ == 'bool'
except NameError:
  _bool_is_builtin = 0

You are right: for 2.2, xmlrpclib.False must be different
from False, since otherwise it would never marshal <boolean>
elements.

I also think you need to conditionally modify WRAPPERS.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-22 16:29

Message:
Logged In: YES 
user_id=44345

Here's a new version.  I think there may still be problems related to 2.2
(see the dump_bool method), but it should be better w.r.t. 2.1 and earlier
versions.  I'd really like to see this get into 2.3.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-07 23:44

Message:
Logged In: YES 
user_id=21627

I think xmlrpclib.{True,False} must stay, even though they 
could become aliases for the builtin True and False (notice 
that you can access True with bool(1))

The module must stay 1.5.2 compatible, I think this is 
currently not the case: dispatching is based on the type, but 
type(True) will be ClassType in 1.5.2.

The test looks for True to determine presence of the boolean 
type; this is incorrect: Python 2.2 has True without having 
bool. The test also binds x without reason. I'd suggest 

try:
  boolean = bool
except:
   ...

instead

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-02 19:03

Message:
Logged In: YES 
user_id=44345

updated patch which avoids using types.BooleanType since there was so 
much pushback on the idea.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-05-22 19:46

Message:
Logged In: YES 
user_id=44345

new patch - don't know why running the test suite didn't catch
the NameError...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470


From noreply@sourceforge.net  Wed Jan 22 17:10:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 22 Jan 2003 09:10:37 -0800
Subject: [Patches] [ python-Patches-559288 ] Use builtin boolean if present
Message-ID: <E18bOOb-0001lO-00@sc8-sf-web1.sourceforge.net>

Patches item #559288, was opened at 2002-05-22 12:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Martin v. Löwis (loewis)
Summary: Use builtin boolean if present

Initial Comment:
Now that Python has a boolean type, perhaps xmlrpclib 
should use it if available.  Here's a patch that (I think) 
does what's necessary.  The existing test case (which 
does manipulate a boolean) passes.  Haven't tested it 
with a pre-bool version of Python though.

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-22 11:10

Message:
Logged In: YES 
user_id=44345

Thanks for the suggestion.  That eases the pain.  All tests pass w/
CVS, 2.2 and 2.1.  I don't have 2.0 or 1.5.2 installed, but since no boolean
stuff is in 2.1 I don't think these changes will break those older versions
either.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 10:09

Message:
Logged In: YES 
user_id=21627

I suggest you introduce a _bool_is_builtin flag early on,
e.g. with

try:
  bla bla bla
  _bool_is_builtin = False.__class__.__name__ == 'bool'
except NameError:
  _bool_is_builtin = 0

You are right: for 2.2, xmlrpclib.False must be different
from False, since otherwise it would never marshal <boolean>
elements.

I also think you need to conditionally modify WRAPPERS.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-22 09:29

Message:
Logged In: YES 
user_id=44345

Here's a new version.  I think there may still be problems related to 2.2
(see the dump_bool method), but it should be better w.r.t. 2.1 and earlier
versions.  I'd really like to see this get into 2.3.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-07 16:44

Message:
Logged In: YES 
user_id=21627

I think xmlrpclib.{True,False} must stay, even though they 
could become aliases for the builtin True and False (notice 
that you can access True with bool(1))

The module must stay 1.5.2 compatible, I think this is 
currently not the case: dispatching is based on the type, but 
type(True) will be ClassType in 1.5.2.

The test looks for True to determine presence of the boolean 
type; this is incorrect: Python 2.2 has True without having 
bool. The test also binds x without reason. I'd suggest 

try:
  boolean = bool
except:
   ...

instead

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-02 12:03

Message:
Logged In: YES 
user_id=44345

updated patch which avoids using types.BooleanType since there was so 
much pushback on the idea.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-05-22 12:46

Message:
Logged In: YES 
user_id=44345

new patch - don't know why running the test suite didn't catch
the NameError...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470


From noreply@sourceforge.net  Wed Jan 22 17:28:17 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 22 Jan 2003 09:28:17 -0800
Subject: [Patches] [ python-Patches-559288 ] Use builtin boolean if present
Message-ID: <E18bOfh-0006tI-00@sc8-sf-web4.sourceforge.net>

Patches item #559288, was opened at 2002-05-22 19:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: Use builtin boolean if present

Initial Comment:
Now that Python has a boolean type, perhaps xmlrpclib 
should use it if available.  Here's a patch that (I think) 
does what's necessary.  The existing test case (which 
does manipulate a boolean) passes.  Haven't tested it 
with a pre-bool version of Python though.

Skip


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 18:28

Message:
Logged In: YES 
user_id=21627

The patch is fine. Please apply it.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-22 18:10

Message:
Logged In: YES 
user_id=44345

Thanks for the suggestion.  That eases the pain.  All tests pass w/
CVS, 2.2 and 2.1.  I don't have 2.0 or 1.5.2 installed, but since no boolean
stuff is in 2.1 I don't think these changes will break those older versions
either.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 17:09

Message:
Logged In: YES 
user_id=21627

I suggest you introduce a _bool_is_builtin flag early on,
e.g. with

try:
  bla bla bla
  _bool_is_builtin = False.__class__.__name__ == 'bool'
except NameError:
  _bool_is_builtin = 0

You are right: for 2.2, xmlrpclib.False must be different
from False, since otherwise it would never marshal <boolean>
elements.

I also think you need to conditionally modify WRAPPERS.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-22 16:29

Message:
Logged In: YES 
user_id=44345

Here's a new version.  I think there may still be problems related to 2.2
(see the dump_bool method), but it should be better w.r.t. 2.1 and earlier
versions.  I'd really like to see this get into 2.3.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-07 23:44

Message:
Logged In: YES 
user_id=21627

I think xmlrpclib.{True,False} must stay, even though they 
could become aliases for the builtin True and False (notice 
that you can access True with bool(1))

The module must stay 1.5.2 compatible, I think this is 
currently not the case: dispatching is based on the type, but 
type(True) will be ClassType in 1.5.2.

The test looks for True to determine presence of the boolean 
type; this is incorrect: Python 2.2 has True without having 
bool. The test also binds x without reason. I'd suggest 

try:
  boolean = bool
except:
   ...

instead

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-02 19:03

Message:
Logged In: YES 
user_id=44345

updated patch which avoids using types.BooleanType since there was so 
much pushback on the idea.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-05-22 19:46

Message:
Logged In: YES 
user_id=44345

new patch - don't know why running the test suite didn't catch
the NameError...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470


From noreply@sourceforge.net  Wed Jan 22 17:29:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 22 Jan 2003 09:29:11 -0800
Subject: [Patches] [ python-Patches-661796 ] BZ2File leaking fd and memory
Message-ID: <E18bOgZ-0002pW-00@sc8-sf-web1.sourceforge.net>

Patches item #661796, was opened at 2003-01-03 14:22
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: BZ2File leaking fd and memory

Initial Comment:
The attached patch fixes BZ2File() leaking the fd and
PyFileObject* info (name, read ahead buffer) when an
object is deleted.

I'm not sure the patch fixes these problems in the best
way.  It exposes most of the implementation from
fileobject.c::file_dealloc() through a private API
_PyFile_Dealloc().
BZ2File derives from PyFileObject.

Make sure the file: 'empty' exists and do: 

  from bz2 import *

A simple test which demonstrates the problem is:

  for i in range(100000): o = BZ2File('empty') ; del o

Without the patch, you quickly get:

IOError: [Errno 24] Too many open files: 'empty'

You can modify this to:

  for i in range(100000): o = BZ2File('empty') ;
o.close() ; del o

Now you can see the memory leaks.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-22 12:29

Message:
Logged In: YES 
user_id=6380

If you could, that would be great.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-01-22 10:39

Message:
Logged In: YES 
user_id=7887

Ok. Do you want me to work on this for 2.3?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-21 14:24

Message:
Logged In: YES 
user_id=6380

FileObject sharing: I see.  But I still think it's a bad
idea, and you're better off using stdio methods directly (as
the evolution of the FileObject implementation has already
shown).

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2003-01-20 15:44

Message:
Logged In: YES 
user_id=7887

Sorry about the delay. I was on a not-so-short vacation.

nnorwitz:

Thanks for the patch. I'll check the problem (for my own
understanding) and most certainly apply it.

gvanrossum:

BZ2File used to share a lot of code with FileObject.
Unfortunately (for the BZ2File side), FileObject changed
considerably post 2.2, and some of the code had to be moved
to BZ2File itself. It still
uses some code from FileObject, though (open, close, seek,
part of the softspace handling, access to attributes and
some common methods).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-05 16:11

Message:
Logged In: YES 
user_id=6380

Um, I don't understand why the BZ2File class inherits from
FileObject. It doesn't seem to be inheriting any code, and
there's no reason to inherit from FileObject just to make a
file-like object. Maybe it was a misunderstanding?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-05 15:09

Message:
Logged In: YES 
user_id=33168

I've found a better solution: change the last line of
BZ2File_dealloc() from: 
  ((PyObject*)self)->ob_type->tp_free((PyObject *)self);

to
  PyFile_Type.tp_dealloc((PyObject *)self);
Updated patch attached.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 14:48

Message:
Logged In: YES 
user_id=21627

Assigning to the author of the module for review. Gustavo,
if you can't find the time for a review, feel free to
unassign it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=661796&group_id=5470


From noreply@sourceforge.net  Wed Jan 22 18:21:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 22 Jan 2003 10:21:40 -0800
Subject: [Patches] [ python-Patches-559288 ] Use builtin boolean if present
Message-ID: <E18bPVM-00046m-00@sc8-sf-web2.sourceforge.net>

Patches item #559288, was opened at 2002-05-22 12:34
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: Use builtin boolean if present

Initial Comment:
Now that Python has a boolean type, perhaps xmlrpclib 
should use it if available.  Here's a patch that (I think) 
does what's necessary.  The existing test case (which 
does manipulate a boolean) passes.  Haven't tested it 
with a pre-bool version of Python though.

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-22 12:21

Message:
Logged In: YES 
user_id=44345

checked in as xmlrpclib.py 1.23 (no new test case needed)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 11:28

Message:
Logged In: YES 
user_id=21627

The patch is fine. Please apply it.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-22 11:10

Message:
Logged In: YES 
user_id=44345

Thanks for the suggestion.  That eases the pain.  All tests pass w/
CVS, 2.2 and 2.1.  I don't have 2.0 or 1.5.2 installed, but since no boolean
stuff is in 2.1 I don't think these changes will break those older versions
either.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 10:09

Message:
Logged In: YES 
user_id=21627

I suggest you introduce a _bool_is_builtin flag early on,
e.g. with

try:
  bla bla bla
  _bool_is_builtin = False.__class__.__name__ == 'bool'
except NameError:
  _bool_is_builtin = 0

You are right: for 2.2, xmlrpclib.False must be different
from False, since otherwise it would never marshal <boolean>
elements.

I also think you need to conditionally modify WRAPPERS.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-22 09:29

Message:
Logged In: YES 
user_id=44345

Here's a new version.  I think there may still be problems related to 2.2
(see the dump_bool method), but it should be better w.r.t. 2.1 and earlier
versions.  I'd really like to see this get into 2.3.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-07 16:44

Message:
Logged In: YES 
user_id=21627

I think xmlrpclib.{True,False} must stay, even though they 
could become aliases for the builtin True and False (notice 
that you can access True with bool(1))

The module must stay 1.5.2 compatible, I think this is 
currently not the case: dispatching is based on the type, but 
type(True) will be ClassType in 1.5.2.

The test looks for True to determine presence of the boolean 
type; this is incorrect: Python 2.2 has True without having 
bool. The test also binds x without reason. I'd suggest 

try:
  boolean = bool
except:
   ...

instead

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-02 12:03

Message:
Logged In: YES 
user_id=44345

updated patch which avoids using types.BooleanType since there was so 
much pushback on the idea.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-05-22 12:46

Message:
Logged In: YES 
user_id=44345

new patch - don't know why running the test suite didn't catch
the NameError...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470


From noreply@sourceforge.net  Wed Jan 22 19:45:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 22 Jan 2003 11:45:59 -0800
Subject: [Patches] [ python-Patches-672656 ] securing pydoc server
Message-ID: <E18bQox-00030G-00@sc8-sf-web3.sourceforge.net>

Patches item #672656, was opened at 2003-01-22 11:45
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672656&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Nobody/Anonymous (nobody)
Summary: securing pydoc server

Initial Comment:
It would be very simple to secure the pydoc server so 
that it doesn't accept connections from external boxes 
as well as provide for a way of extending connections to 
trusted hosts by keeping a list of valid IP addresses. 
This would make pydoc suitable for running on boxes 
that aren't behind firewalls, which currently it is not; 
most home machines don't have a firewall and are 
regularly port scanned by script kiddies...

Since pydoc does not log connections, you can't tell 
who is connecting to your machine or what they are 
trying to reach. My solution is to simply make the 
default pydoc server only accept connections from the 
host it was started on.

The change is for the DocServer class. a validIPList 
keeps track of the IP addresses that can legally connect 
to the server. The verify_request method is overridden to 
enforce this rule.

            import socket
            self.validIPList = ['127.0.0.1']
            self.validIPList.append(socket.gethostbyname
(socket.gethostname()))


        def verify_request(self, request, client_address):
            if client_address[0] in self.validIPList:
                return 1
            else:
                return 0

This patch does not provide a UI change to allow the 
user to easily add additional IP addresses. If that is 
desired because of the assumption that people typically 
run the pydoc server not for personal use, but for a group 
of machines to reach, then the simplest change would 
be to have a checkbox for "Allow any host to connect" 
and then have a self.allowAny member variable to reflect 
that checkbox state, so the verify_request becomes

    def verify_request(self, request, client_address):
        if self.allowAny or client_address[0] in 
self.validIPList:
            return 1
        else:
            return 0

ka

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672656&group_id=5470


From noreply@sourceforge.net  Thu Jan 23 01:05:38 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 22 Jan 2003 17:05:38 -0800
Subject: [Patches] [ python-Patches-672855 ] improve pydoc handling of extension types
Message-ID: <E18bVoI-0005h3-00@sc8-sf-web1.sourceforge.net>

Patches item #672855, was opened at 2003-01-22 20:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672855&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoff Talvola (gtalvola)
Assigned to: Nobody/Anonymous (nobody)
Summary: improve pydoc handling of extension types

Initial Comment:
pydoc.HTMLRepr.repr1() generates an exception if you
pass in an object x where type(x) has no __name__
attribute.  The attached patch adds a test for this
case and keeps repr1 from barfing.

This is useful on Windows if you're using cgitb.py to
try to get tracebacks that involve COM objects --
somewhere in the guts of the COM support code you get a
type that has no __name__ attribute.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672855&group_id=5470


From noreply@sourceforge.net  Thu Jan 23 22:49:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 23 Jan 2003 14:49:27 -0800
Subject: [Patches] [ python-Patches-636005 ] Filter unicode into unicode
Message-ID: <E18bqA3-0003mJ-00@sc8-sf-web2.sourceforge.net>

Patches item #636005, was opened at 2002-11-09 15:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=636005&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Filter unicode into unicode

Initial Comment:
Currently, filter(None, "abc") gives "abc", but
filter(None, u"abc") gives [u'a', u'b', u'c']. This
patches corrects this, adding a Unicode specical case
for filter.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-23 17:49

Message:
Logged In: YES 
user_id=80475

Looks good, compiles fine, passes regrtests, doesn't 
appear to have any leaks, and looks like a faithful 
interpretation of filterstring() just above it.

Consider expanding the tests to verify the
return type.  Since 'abc' == u'abc', the
current tests would pass even if the return
type were a non-unicode string.

Please apply.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 16:38

Message:
Logged In: YES 
user_id=21627

Argh! I lost it, so I had to recreate. It is attached now.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 22:04

Message:
Logged In: YES 
user_id=80475

Do you still have this patch available?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-11-11 04:11

Message:
Logged In: YES 
user_id=38388

There's no patch attached to this SF item, but
you're right, filter() should behave in the same
way for 8-bit strings as for Unicode.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=636005&group_id=5470


From noreply@sourceforge.net  Sat Jan 25 00:18:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 24 Jan 2003 16:18:10 -0800
Subject: [Patches] [ python-Patches-669683 ] HTMLParser -- allow "," in attributes
Message-ID: <E18cE1S-0000bX-00@sc8-sf-web4.sourceforge.net>

Patches item #669683, was opened at 2003-01-17 11:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
>Summary: HTMLParser -- allow "," in attributes

Initial Comment:
An HTML document in the wild had the tag:

<font size="-1" color=rgb(175,18,3)>

and HTMLParser was choking on the "," after the 
"175".  By adding "," to the list of allowed characters 
in attribute values, HTMLParser accepts the document.


----------------------------------------------------------------------

>Comment By: j paulson (fantoozler)
Date: 2003-01-25 00:18

Message:
Logged In: YES 
user_id=690612

Added test case to Lib/test/test_htmlparser.py in addition to the 
HTMLParser.py patch

----------------------------------------------------------------------

Comment By: j paulson (fantoozler)
Date: 2003-01-17 18:46

Message:
Logged In: YES 
user_id=690612

I'll attach the patch file again.  

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-17 14:17

Message:
Logged In: YES 
user_id=33168

Was this supposed to be a patch or a bug report?  There is
no patch attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470


From noreply@sourceforge.net  Sat Jan 25 01:01:57 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 24 Jan 2003 17:01:57 -0800
Subject: [Patches] [ python-Patches-674396 ] Expand dbshelve to have full shelve/dict interface
Message-ID: <E18cEhp-000213-00@sc8-sf-web4.sourceforge.net>

Patches item #674396, was opened at 2003-01-24 20:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674396&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: A.M. Kuchling (akuchling)
Summary: Expand dbshelve to have full shelve/dict interface

Initial Comment:
Use the new DictMixin to grant all mapping methods 
to dbshelve.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674396&group_id=5470


From noreply@sourceforge.net  Sat Jan 25 01:30:40 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 24 Jan 2003 17:30:40 -0800
Subject: [Patches] [ python-Patches-636005 ] Filter unicode into unicode
Message-ID: <E18cF9c-0005Fv-00@sc8-sf-web3.sourceforge.net>

Patches item #636005, was opened at 2002-11-09 15:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=636005&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Martin v. Löwis (loewis)
Summary: Filter unicode into unicode

Initial Comment:
Currently, filter(None, "abc") gives "abc", but
filter(None, u"abc") gives [u'a', u'b', u'c']. This
patches corrects this, adding a Unicode specical case
for filter.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-23 17:49

Message:
Logged In: YES 
user_id=80475

Looks good, compiles fine, passes regrtests, doesn't 
appear to have any leaks, and looks like a faithful 
interpretation of filterstring() just above it.

Consider expanding the tests to verify the
return type.  Since 'abc' == u'abc', the
current tests would pass even if the return
type were a non-unicode string.

Please apply.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 16:38

Message:
Logged In: YES 
user_id=21627

Argh! I lost it, so I had to recreate. It is attached now.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-18 22:04

Message:
Logged In: YES 
user_id=80475

Do you still have this patch available?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-11-11 04:11

Message:
Logged In: YES 
user_id=38388

There's no patch attached to this SF item, but
you're right, filter() should behave in the same
way for 8-bit strings as for Unicode.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=636005&group_id=5470


From noreply@sourceforge.net  Sat Jan 25 03:48:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 24 Jan 2003 19:48:53 -0800
Subject: [Patches] [ python-Patches-669683 ] HTMLParser -- allow "," in attributes
Message-ID: <E18cHJN-0007ya-00@sc8-sf-web2.sourceforge.net>

Patches item #669683, was opened at 2003-01-17 11:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
>Summary: HTMLParser -- allow "," in attributes

Initial Comment:
An HTML document in the wild had the tag:

<font size="-1" color=rgb(175,18,3)>

and HTMLParser was choking on the "," after the 
"175".  By adding "," to the list of allowed characters 
in attribute values, HTMLParser accepts the document.


----------------------------------------------------------------------

Comment By: j paulson (fantoozler)
Date: 2003-01-25 00:18

Message:
Logged In: YES 
user_id=690612

Added test case to Lib/test/test_htmlparser.py in addition to the 
HTMLParser.py patch

----------------------------------------------------------------------

Comment By: j paulson (fantoozler)
Date: 2003-01-17 18:46

Message:
Logged In: YES 
user_id=690612

I'll attach the patch file again.  

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-17 14:17

Message:
Logged In: YES 
user_id=33168

Was this supposed to be a patch or a bug report?  There is
no patch attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470


From noreply@sourceforge.net  Sat Jan 25 03:58:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 24 Jan 2003 19:58:04 -0800
Subject: [Patches] [ python-Patches-670664 ] HTMLParser.py - more robust <SCRIPT> parsing
Message-ID: <E18cHSG-0000LI-00@sc8-sf-web3.sourceforge.net>

Patches item #670664, was opened at 2003-01-19 14:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTMLParser.py - more robust <SCRIPT> parsing

Initial Comment:
http://www.ebay.com contains a script element of the form

<SCRIPT>
...
   vbscript += "</SCR"+"IPT> \n";
...
</SCRIPT>

which is not enclosed in "<!-- ... -->" comments.  The parser 
choked on that line, indicating it was a mal-formed end tag.

The changes are:

  interesting_cdata is now a dict mapping start tag to
    an re matching the end tag, a "<--" or \Z

  HTMLParser.set_cdata_mode takes an extra argument, 
    the start tag


----------------------------------------------------------------------

>Comment By: j paulson (fantoozler)
Date: 2003-01-25 03:58

Message:
Logged In: YES 
user_id=690612

Found regression test, used it, found error, fixed it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470


From noreply@sourceforge.net  Sat Jan 25 04:00:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 24 Jan 2003 20:00:29 -0800
Subject: [Patches] [ python-Patches-674448 ] test_htmlparser.py -- "," in attributes
Message-ID: <E18cHUb-0008P9-00@sc8-sf-web2.sourceforge.net>

Patches item #674448, was opened at 2003-01-25 04:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674448&group_id=5470

Category: Tests
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_htmlparser.py -- "," in attributes

Initial Comment:
Added a test verifying patch #669683 works.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674448&group_id=5470


From noreply@sourceforge.net  Sat Jan 25 04:02:34 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 24 Jan 2003 20:02:34 -0800
Subject: [Patches] [ python-Patches-674449 ] test_htmlparser -- more robust <SCRIPT> handling
Message-ID: <E18cHWc-0006x5-00@sc8-sf-web4.sourceforge.net>

Patches item #674449, was opened at 2003-01-25 04:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674449&group_id=5470

Category: Tests
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_htmlparser -- more robust <SCRIPT> handling

Initial Comment:
This test verifies that patch 670664 works

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674449&group_id=5470


From noreply@sourceforge.net  Sat Jan 25 04:02:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 24 Jan 2003 20:02:43 -0800
Subject: [Patches] [ python-Patches-669683 ] HTMLParser -- allow "," in attributes
Message-ID: <E18cHWl-0008Tw-00@sc8-sf-web2.sourceforge.net>

Patches item #669683, was opened at 2003-01-17 11:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
>Summary: HTMLParser -- allow "," in attributes

Initial Comment:
An HTML document in the wild had the tag:

<font size="-1" color=rgb(175,18,3)>

and HTMLParser was choking on the "," after the 
"175".  By adding "," to the list of allowed characters 
in attribute values, HTMLParser accepts the document.


----------------------------------------------------------------------

Comment By: j paulson (fantoozler)
Date: 2003-01-25 00:18

Message:
Logged In: YES 
user_id=690612

Added test case to Lib/test/test_htmlparser.py in addition to the 
HTMLParser.py patch

----------------------------------------------------------------------

Comment By: j paulson (fantoozler)
Date: 2003-01-17 18:46

Message:
Logged In: YES 
user_id=690612

I'll attach the patch file again.  

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-17 14:17

Message:
Logged In: YES 
user_id=33168

Was this supposed to be a patch or a bug report?  There is
no patch attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470


From noreply@sourceforge.net  Sat Jan 25 04:04:41 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 24 Jan 2003 20:04:41 -0800
Subject: [Patches] [ python-Patches-674448 ] test_htmlparser.py -- "," in attributes
Message-ID: <E18cHYf-0006za-00@sc8-sf-web4.sourceforge.net>

Patches item #674448, was opened at 2003-01-25 04:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674448&group_id=5470

Category: Tests
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Nobody/Anonymous (nobody)
>Summary: test_htmlparser.py -- "," in attributes

Initial Comment:
Added a test verifying patch #669683 works.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674448&group_id=5470


From noreply@sourceforge.net  Sat Jan 25 18:58:11 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 25 Jan 2003 10:58:11 -0800
Subject: [Patches] [ python-Patches-638299 ] LaTeX documentation for logging package
Message-ID: <E18cVVL-0007mv-00@sc8-sf-web3.sourceforge.net>

Patches item #638299, was opened at 2002-11-14 09:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=638299&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Vinay Sajip (vsajip)
Assigned to: Skip Montanaro (montanaro)
Summary: LaTeX documentation for logging package

Initial Comment:
I've attached the LaTeX documentation for the logging 
package (PEP 282) and a minor patch (fileConfig() now 
takes an optional defaults dictionary parameter which is 
passed to ConfigParser.



----------------------------------------------------------------------

>Comment By: Vinay Sajip (vsajip)
Date: 2003-01-25 18:58

Message:
Logged In: YES 
user_id=308438

Updated version of liblogging.tex, contains details of 
configuration file format.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-14 12:53

Message:
Logged In: YES 
user_id=6380

Skip, can you merge this with your work? (Or override, as
you see fit?)

Sorry for the duplicate work!

I already took care of the config.py patch.

Vinaj, are there unit tests for the logging package?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=638299&group_id=5470


From noreply@sourceforge.net  Sat Jan 25 21:34:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 25 Jan 2003 13:34:33 -0800
Subject: [Patches] [ python-Patches-638299 ] LaTeX documentation for logging package
Message-ID: <E18cXwf-0004un-00@sc8-sf-web3.sourceforge.net>

Patches item #638299, was opened at 2002-11-14 04:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=638299&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Vinay Sajip (vsajip)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: LaTeX documentation for logging package

Initial Comment:
I've attached the LaTeX documentation for the logging 
package (PEP 282) and a minor patch (fileConfig() now 
takes an optional defaults dictionary parameter which is 
passed to ConfigParser.



----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-25 16:34

Message:
Logged In: YES 
user_id=33168

Checked in as liblogging.tex 1.4
with markup modifications and wrapped some long lines.

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2003-01-25 13:58

Message:
Logged In: YES 
user_id=308438

Updated version of liblogging.tex, contains details of 
configuration file format.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-14 07:53

Message:
Logged In: YES 
user_id=6380

Skip, can you merge this with your work? (Or override, as
you see fit?)

Sorry for the duplicate work!

I already took care of the config.py patch.

Vinaj, are there unit tests for the logging package?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=638299&group_id=5470


From noreply@sourceforge.net  Sat Jan 25 22:50:47 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 25 Jan 2003 14:50:47 -0800
Subject: [Patches] [ python-Patches-636005 ] Filter unicode into unicode
Message-ID: <E18cZ8R-0005y2-00@sc8-sf-web2.sourceforge.net>

Patches item #636005, was opened at 2002-11-09 21:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=636005&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Martin v. Löwis (loewis)
Summary: Filter unicode into unicode

Initial Comment:
Currently, filter(None, "abc") gives "abc", but
filter(None, u"abc") gives [u'a', u'b', u'c']. This
patches corrects this, adding a Unicode specical case
for filter.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-25 23:50

Message:
Logged In: YES 
user_id=21627

Committed as

test_builtin.py 1.4
NEWS 1.625
bltinmodule.c 2.271


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-23 23:49

Message:
Logged In: YES 
user_id=80475

Looks good, compiles fine, passes regrtests, doesn't 
appear to have any leaks, and looks like a faithful 
interpretation of filterstring() just above it.

Consider expanding the tests to verify the
return type.  Since 'abc' == u'abc', the
current tests would pass even if the return
type were a non-unicode string.

Please apply.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 22:38

Message:
Logged In: YES 
user_id=21627

Argh! I lost it, so I had to recreate. It is attached now.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-19 04:04

Message:
Logged In: YES 
user_id=80475

Do you still have this patch available?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-11-11 10:11

Message:
Logged In: YES 
user_id=38388

There's no patch attached to this SF item, but
you're right, filter() should behave in the same
way for 8-bit strings as for Unicode.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=636005&group_id=5470


From noreply@sourceforge.net  Sun Jan 26 02:19:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sat, 25 Jan 2003 18:19:00 -0800
Subject: [Patches] [ python-Patches-642974 ] logging SysLogHandler proto type wrong
Message-ID: <E18ccNw-00051G-00@sc8-sf-web3.sourceforge.net>

Patches item #642974, was opened at 2002-11-24 00:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=642974&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Chris McDonough (chrism)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: logging SysLogHandler proto type wrong 

Initial Comment:
The (new) logging module's handlers.SysLogHandler has
an incorrect protocol type when the address is a
file-like object.  It fails during connect as a result.
 A patch is as follows:

--- handlers.py 13 Nov 2002 16:18:29 -0000      1.2
+++ handlers.py 24 Nov 2002 05:36:51 -0000
@@ -348,7 +348,7 @@
         self.address = address
         self.facility = facility
         if type(address) == types.StringType:
-            self.socket =
socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
+            self.socket =
socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM)
             self.socket.connect(address)
             self.unixsocket = 1
         else:


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-25 21:18

Message:
Logged In: YES 
user_id=33168

Thanks!  Checked in as Lib/logging/handlers.py 1.3

----------------------------------------------------------------------

Comment By: Vinay Sajip (vsajip)
Date: 2003-01-03 06:12

Message:
Logged In: YES 
user_id=308438

I'm happy to accept the patch, though I cannot test at the 
moment due to a hardware failure of my Linux machine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=642974&group_id=5470


From noreply@sourceforge.net  Sun Jan 26 11:32:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 26 Jan 2003 03:32:44 -0800
Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv
Message-ID: <E18cl1o-0006kb-00@sc8-sf-web2.sourceforge.net>

Patches item #670715, was opened at 2003-01-19 17:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Martin v. Löwis (loewis)
Summary: Universal Unicode Codec for POSIX iconv

Initial Comment:
Here's the unicode codec using POSIX iconv(3) library.

Tested on these platforms and seems to work:
  FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64,
  FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2

This codec implementation supports PEP293, also.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-01-26 12:32

Message:
Logged In: YES 
user_id=21627

I have committed it now with minimal changes so that it
works on Linux, as

setup.py 1.138
__init__.py 1.15
iconv_codec.py 1.1
regrtest.py 1.117
NEWS 1.627

I will make further changes; please watch the CVS. If you
would like to make further changes, please submit patches
against the CVS.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 02:07

Message:
Logged In: YES 
user_id=21627

Hmm. I see that Solaris does support conversion of CJK to
UTF-8. So even though we cannot convert into the internal
encoding, we could still convert through UTF-8.

Looking at /usr/lib/nls/iconv/config.iconv of HP-UX 11.11, I
see conversions from and to ucs2, for iso-8859, eucJP, sjis,
eucTW, big5, roc15, kore5, hp15CN, and many IBM code pages.

So I think the iconv codec should convert into the Python
internal representation if possible. If no encoding name for
that is known, it should convert to ucs2 (be) if possible,
or else to UTF-8; in all cases, it will then construct a
Unicode object from the resulting string.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-22 01:21

Message:
Logged In: YES 
user_id=55188

iconv implementations on commercial UNIXes are very scary. 

Solaris implementation:
  no support for CJK <-> UCS conversion.
  They support UCS[24] only for iso-8859 and UTFs.

HP-UX implementation:
  They have useless iconv. HP-UX iconv has no unicode support.

BSD implementation (Konstantin Chuguev's):
  compatible with this patch (provides ucs-[24]-internal)

GLIBC implementation:
  provides ucs-[24] and they are same with GNU iconv's
ucs-[24]-internal.
  Because ucs-[24] of GNU/BSD implentation is big endian
always. We can't use ucs-[24] for every platform.

In conclusion, we must use 3rd party iconv on Solaris or HP-UX.
And, we need to detect whether the linked iconv is GNU/BSD
iconv or GLIBC iconv. (how?)

I'll investigate how to detect them, but ... :)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 23:27

Message:
Logged In: YES 
user_id=21627

I'm quite happy with this patch, and will apply it shortly.
However, I am concerned that it is specific for GNU iconv.
IMO, there should be machinery to find out the "internal"
encoding, in case native the native iconv implementation is
used instead of GNU iconv.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-20 14:33

Message:
Logged In: YES 
user_id=55188

Thank you for comments. :->
I uploaded a new revised patch with unittest and some code
style fixes.

I saw Martin v. Loewis's iconvcodecs about a years ago.
His implementation is very neat, but it had a limit on error
handling due to recursive call.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-19 23:56

Message:
Logged In: YES 
user_id=38388

The patch looks good, but you'll need to add some form
of testing to underline the "seems to work" :-)

Some docs on how to use the codec would also be needed.

Martin von Loewis has written a similar codec some months ago.
Perhaps you two could get in touch and sort out the details ?!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470


From noreply@sourceforge.net  Sun Jan 26 15:19:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 26 Jan 2003 07:19:03 -0800
Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv
Message-ID: <E18coYp-0007Hn-00@sc8-sf-web4.sourceforge.net>

Patches item #670715, was opened at 2003-01-20 01:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Martin v. Löwis (loewis)
Summary: Universal Unicode Codec for POSIX iconv

Initial Comment:
Here's the unicode codec using POSIX iconv(3) library.

Tested on these platforms and seems to work:
  FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64,
  FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2

This codec implementation supports PEP293, also.


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2003-01-27 00:19

Message:
Logged In: YES 
user_id=55188

Thank you very much for your works.
I'm working on UCS endian detection and UCS transparent 
wrapper for UTF-{8,16}. I'll submit new patch in a week.
Please feel free to change my codes because I'm not familiar 
with python code convention and culture. :-)


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-26 20:32

Message:
Logged In: YES 
user_id=21627

I have committed it now with minimal changes so that it
works on Linux, as

setup.py 1.138
__init__.py 1.15
iconv_codec.py 1.1
regrtest.py 1.117
NEWS 1.627

I will make further changes; please watch the CVS. If you
would like to make further changes, please submit patches
against the CVS.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 10:07

Message:
Logged In: YES 
user_id=21627

Hmm. I see that Solaris does support conversion of CJK to
UTF-8. So even though we cannot convert into the internal
encoding, we could still convert through UTF-8.

Looking at /usr/lib/nls/iconv/config.iconv of HP-UX 11.11, I
see conversions from and to ucs2, for iso-8859, eucJP, sjis,
eucTW, big5, roc15, kore5, hp15CN, and many IBM code pages.

So I think the iconv codec should convert into the Python
internal representation if possible. If no encoding name for
that is known, it should convert to ucs2 (be) if possible,
or else to UTF-8; in all cases, it will then construct a
Unicode object from the resulting string.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-22 09:21

Message:
Logged In: YES 
user_id=55188

iconv implementations on commercial UNIXes are very scary. 

Solaris implementation:
  no support for CJK <-> UCS conversion.
  They support UCS[24] only for iso-8859 and UTFs.

HP-UX implementation:
  They have useless iconv. HP-UX iconv has no unicode support.

BSD implementation (Konstantin Chuguev's):
  compatible with this patch (provides ucs-[24]-internal)

GLIBC implementation:
  provides ucs-[24] and they are same with GNU iconv's
ucs-[24]-internal.
  Because ucs-[24] of GNU/BSD implentation is big endian
always. We can't use ucs-[24] for every platform.

In conclusion, we must use 3rd party iconv on Solaris or HP-UX.
And, we need to detect whether the linked iconv is GNU/BSD
iconv or GLIBC iconv. (how?)

I'll investigate how to detect them, but ... :)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 07:27

Message:
Logged In: YES 
user_id=21627

I'm quite happy with this patch, and will apply it shortly.
However, I am concerned that it is specific for GNU iconv.
IMO, there should be machinery to find out the "internal"
encoding, in case native the native iconv implementation is
used instead of GNU iconv.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-20 22:33

Message:
Logged In: YES 
user_id=55188

Thank you for comments. :->
I uploaded a new revised patch with unittest and some code
style fixes.

I saw Martin v. Loewis's iconvcodecs about a years ago.
His implementation is very neat, but it had a limit on error
handling due to recursive call.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-20 07:56

Message:
Logged In: YES 
user_id=38388

The patch looks good, but you'll need to add some form
of testing to underline the "seems to work" :-)

Some docs on how to use the codec would also be needed.

Martin von Loewis has written a similar codec some months ago.
Perhaps you two could get in touch and sort out the details ?!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470


From noreply@sourceforge.net  Sun Jan 26 19:20:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Sun, 26 Jan 2003 11:20:43 -0800
Subject: [Patches] [ python-Patches-675034 ] More flexible py-shell interpreter selection
Message-ID: <E18csKh-0005JK-00@sc8-sf-web1.sourceforge.net>

Patches item #675034, was opened at 2003-01-26 14:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675034&group_id=5470

Category: Demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Haggerty (mhagger)
Assigned to: Nobody/Anonymous (nobody)
Summary: More flexible py-shell interpreter selection

Initial Comment:
Currently in python-mode.el, py-which-shell (the
command used to start the python interpreter) is
limited to "python" or "jpython".  This patch makes it
possible to specify an arbitrary command at invocation
time, including a command that is specified relative to
the current path.

The problem: I am working on a project where jython is
embedded within our application.  The application
optionally allows console access to the jython
interpreter.  The application is started by running a
shell script which sets some environment variables then
invokes the jython interpreter with a large number of
arguments.

I would like to use py-shell within emacs to interact
with the application.  However, it is impractical to
start the application under py-shell for two reasons:

1. The command that needs to be invoked is neither
"python" nor "jython", and in fact would require many
arguments;

2. The command is not necessary installed in the PATH.

Similar problems occur even if one sometimes wants to
start an alternative python interpreter (such as
"python2" under redhat) or an interpreter that is not
in PATH (for example, if testing a new version of
python).

Therefore I have written a patch to python-mode.py that
changes the py-shell command as follows:

+ If there is no prefix argument, the usual python (or
jython) interpreter is invoked without further
interaction as before.

+ If there is a prefix argument, then the user is asked
what command to invoke with the "standard command" as
the default input:

    command: python -i

The user can edit the command to run whatever s/he
wants.

+ The command typed by the user is invoked via "$SHELL
-c 'COMMAND'" so that the user's program is first
sought in the emacs default directory (generally, the
directory related to the current emacs buffer).  This
allows the user to type, for example,

    command: ./my_test_interpreter -i

I am a novice at emacs lisp, but the patch is simple
(only about 10 lines changed) and it seems to work for
me.

The patch applies to the CVS version of python-mode.el
as of today (2003-01-26), but the same patch can be
applied to the version that was released with
Python-2.1.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675034&group_id=5470


From noreply@sourceforge.net  Mon Jan 27 13:42:14 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 27 Jan 2003 05:42:14 -0800
Subject: [Patches] [ python-Patches-675422 ] Add tzset method to time module
Message-ID: <E18d9Wg-00008A-00@sc8-sf-web1.sourceforge.net>

Patches item #675422, was opened at 2003-01-28 00:42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675422&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add tzset method to time module

Initial Comment:
Adds access to the tzset method, allowing you to change your local timezone as required. In addition to invoking the tzset system
call, the code also updates the timezone attributes (time.timezone etc). This lets you do timezone conversions amongst other things.

Also includes changes to configure.in to only build new code if the tzset method correctly switches timezones on your platform. This 
should be for all modern Unixes, and possibly other platforms.

Also includes tests in test_time.py

Docs would be along the lines of:

tzset() -- 
Initialize, or reinitialize, the local timezone to the value stored in os.environ['TZ']. The TZ environment variable should be specified in
standard Uniz timezone format as documented in the tzset man page
(eg. 'US/Eastern', 'Europe/Amsterdam'). Unknown timezones will silently fall back to UTC. If the TZ environment variable is not set, the local timezone is set to the systems best guess of wallclock time.
Changing the TZ environment variable without calling tzset *may* change the local timezone used by methods such as localtime, but this behaviour should not be relied on.

eg::

>>> now = time.time()
>>> os.environ['TZ'] = 'Europe/Amsterdam'
>>> time.tzset()
>>> time.ctime(now)
'Mon Jan 27 14:35:17 2003'
>>> time.tzname  
('CET', 'CEST')
>>> os.environ['TZ'] = 'US/Eastern'
>>> time.tzset()
>>> time.ctime(now)
'Mon Jan 27 08:35:17 2003'
>>> time.tzname
('EST', 'EDT')

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675422&group_id=5470


From noreply@sourceforge.net  Mon Jan 27 16:52:33 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 27 Jan 2003 08:52:33 -0800
Subject: [Patches] [ python-Patches-675551 ] extending readline functionality
Message-ID: <E18dCUr-0001ig-00@sc8-sf-web1.sourceforge.net>

Patches item #675551, was opened at 2003-01-27 17:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675551&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Michal Vitecek (fufsource)
Assigned to: Nobody/Anonymous (nobody)
Summary: extending readline functionality

Initial Comment:
this patch against vanilla 2.2.2 adds three new functions to module readline:

remove_history(pos) -- remove history entry specified by pos

replace_history_entry(pos, line) -- replace history entry specified by pos with the given line

get_history_buffer_size() -- get current number of history entries

the libreadline.tex is also modified.

thank you for your consideration.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675551&group_id=5470


From noreply@sourceforge.net  Mon Jan 27 20:05:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 27 Jan 2003 12:05:04 -0800
Subject: [Patches] [ python-Patches-675698 ] New block cipher API
Message-ID: <E18dFVA-0005Fs-00@sc8-sf-web2.sourceforge.net>

Patches item #675698, was opened at 2003-01-27 20:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675698&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: New block cipher API

Initial Comment:
This is a preliminary, pure-Python implementation of a
new block cipher API, superseding PEP 272 (I've been in
contact with Andrew about it and he says it's ok). 
It's loosely patterned after the Java cipher classes,
but less fancy and maybe more Pythonic.  The API is
divided into two layers, a "codebook" layer which
implements a raw block cipher (like DES or AES), and a
"modes of operation" layer which implements the
standard FIPS modes (ECB, CTR, CBC, CFB, OFB) by
calling the codebook layer.  There's just one "modes of
operation" module, which can call any codebook
interchangeably.  This makes more sense to me than PEP
272, which required each codebook module to implement
all the FIPS modes itself.

I'm hoping to finalize the API and submit a C
implementation, along with C implementations of
DES/3DES and AES in time for 2.3a2.  I'm submitting
this Python version as a patch per Andrew's suggestion,
to get it onto the radar for upcoming releases.  The
Python version includes 64- and 128-bit block ciphers
based on the Luby-Rackoff construction with SHA1 as the
round function.  This is mainly for reference and
testing purposes--while these ciphers should be secure,
they're pretty slow and won't interoperate with
anything else out there.

There is a test harness included, "test.py", which
works under Linux and Cygwin.  It won't work under
Windows because it depends on a random number module
(included) that uses a Linux system device.  I have a
separate effort (i.e. search for volunteers with
Windows dev tools) to provide a Windows RNG that calls
the Windows CAPI to get random numbers.

Note: I haven't tested the Python implementation
extensively, since it's intended as a throwaway.  Don't
use it for anything serious.  Before submitting a C
module, I'll make sure that all the FIPS test vectors
work for all the modes.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675698&group_id=5470


From noreply@sourceforge.net  Mon Jan 27 20:09:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 27 Jan 2003 12:09:00 -0800
Subject: [Patches] [ python-Patches-675698 ] New block cipher API
Message-ID: <E18dFYy-0007sv-00@sc8-sf-web3.sourceforge.net>

Patches item #675698, was opened at 2003-01-27 20:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675698&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: New block cipher API

Initial Comment:
This is a preliminary, pure-Python implementation of a
new block cipher API, superseding PEP 272 (I've been in
contact with Andrew about it and he says it's ok). 
It's loosely patterned after the Java cipher classes,
but less fancy and maybe more Pythonic.  The API is
divided into two layers, a "codebook" layer which
implements a raw block cipher (like DES or AES), and a
"modes of operation" layer which implements the
standard FIPS modes (ECB, CTR, CBC, CFB, OFB) by
calling the codebook layer.  There's just one "modes of
operation" module, which can call any codebook
interchangeably.  This makes more sense to me than PEP
272, which required each codebook module to implement
all the FIPS modes itself.

I'm hoping to finalize the API and submit a C
implementation, along with C implementations of
DES/3DES and AES in time for 2.3a2.  I'm submitting
this Python version as a patch per Andrew's suggestion,
to get it onto the radar for upcoming releases.  The
Python version includes 64- and 128-bit block ciphers
based on the Luby-Rackoff construction with SHA1 as the
round function.  This is mainly for reference and
testing purposes--while these ciphers should be secure,
they're pretty slow and won't interoperate with
anything else out there.

There is a test harness included, "test.py", which
works under Linux and Cygwin.  It won't work under
Windows because it depends on a random number module
(included) that uses a Linux system device.  I have a
separate effort (i.e. search for volunteers with
Windows dev tools) to provide a Windows RNG that calls
the Windows CAPI to get random numbers.

Note: I haven't tested the Python implementation
extensively, since it's intended as a throwaway.  Don't
use it for anything serious.  Before submitting a C
module, I'll make sure that all the FIPS test vectors
work for all the modes.


----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2003-01-27 20:09

Message:
Logged In: YES 
user_id=72053

Somehow the file attachment didn't work.  Oh well.  The
reference implementation is at:

http://www.nightsong.com/phr/crypto/blockcipher.tgz


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675698&group_id=5470


From noreply@sourceforge.net  Mon Jan 27 21:52:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 27 Jan 2003 13:52:59 -0800
Subject: [Patches] [ python-Patches-675750 ] allow timeouts with SSL
Message-ID: <E18dHBb-0000GZ-00@sc8-sf-web1.sourceforge.net>

Patches item #675750, was opened at 2003-01-27 16:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675750&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoff Talvola (gtalvola)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow timeouts with SSL

Initial Comment:
This fixes bug 675552 -- it patches the read() and
write() methods of the SSL objects so that they use the
timeout settings of the socket that the SSL object is
wrapping.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675750&group_id=5470


From noreply@sourceforge.net  Mon Jan 27 21:57:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 27 Jan 2003 13:57:24 -0800
Subject: [Patches] [ python-Patches-675750 ] allow timeouts with SSL
Message-ID: <E18dHFs-0006X3-00@sc8-sf-web4.sourceforge.net>

Patches item #675750, was opened at 2003-01-27 16:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675750&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoff Talvola (gtalvola)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: allow timeouts with SSL

Initial Comment:
This fixes bug 675552 -- it patches the read() and
write() methods of the SSL objects so that they use the
timeout settings of the socket that the SSL object is
wrapping.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675750&group_id=5470


From noreply@sourceforge.net  Mon Jan 27 22:24:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 27 Jan 2003 14:24:48 -0800
Subject: [Patches] [ python-Patches-675750 ] allow timeouts with SSL
Message-ID: <E18dHgO-000632-00@sc8-sf-web3.sourceforge.net>

Patches item #675750, was opened at 2003-01-27 16:52
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675750&group_id=5470

Category: Modules
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Geoff Talvola (gtalvola)
Assigned to: Guido van Rossum (gvanrossum)
Summary: allow timeouts with SSL

Initial Comment:
This fixes bug 675552 -- it patches the read() and
write() methods of the SSL objects so that they use the
timeout settings of the socket that the SSL object is
wrapping.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-27 17:24

Message:
Logged In: YES 
user_id=6380

Thanks! Checked in as _ssl.c rev. 1.9.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675750&group_id=5470


From noreply@sourceforge.net  Tue Jan 28 00:21:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 27 Jan 2003 16:21:32 -0800
Subject: [Patches] [ python-Patches-671384 ] test_pty hanging on hpux11
Message-ID: <E18dJVM-00073d-00@sc8-sf-web1.sourceforge.net>

Patches item #671384, was opened at 2003-01-20 16:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671384&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Martin v. Löwis (loewis)
Summary: test_pty hanging on hpux11

Initial Comment:
The attached hack fixes a problem which occurs since
switching the pty code.  isatty() hangs if the slave_fd
is closed and reopened as in the deprecated APIs
pty.master_open() and pty.slave_open().

This patch reverts to the old behaviour where
_open_terminal() is called in master_open() to avoid
the hang later.

Here's a very simple test for the problem:

import pty, os

master_fd, slave_name = pty.master_open()
slave_fd = pty.slave_open(slave_name)
print os.isatty(slave_fd)

In slave_open() the first ioctl raises an IOError,
Invalid Argument 22.

I don't know if this problem affects hpux10.  Hopefully
someone will have a better idea how to really fix this
problem.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-27 19:21

Message:
Logged In: YES 
user_id=33168

I have attached an updated patch.  It seems Solaris 8 (on
the snake farm) also had a test failure.  I have basically
restored the old functionality in this patch. 
_open_terminal is called if /dev/ptmx exists, so
os.openpty() is not called.  This fixes the test
failures/hangs on both solaris and hpux and should be
equivalent to the 2.2 behaviour.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671384&group_id=5470


From noreply@sourceforge.net  Tue Jan 28 05:04:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 27 Jan 2003 21:04:59 -0800
Subject: [Patches] [ python-Patches-674449 ] test_htmlparser -- more robust &lt;SCRIPT&gt; handling
Message-ID: <E18dNvf-0000cn-00@sc8-sf-web2.sourceforge.net>

Patches item #674449, was opened at 2003-01-24 23:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674449&group_id=5470

>Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
>Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: test_htmlparser -- more robust &lt;SCRIPT&gt; handling

Initial Comment:
This test verifies that patch 670664 works

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674449&group_id=5470


From noreply@sourceforge.net  Tue Jan 28 05:04:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 27 Jan 2003 21:04:59 -0800
Subject: [Patches] [ python-Patches-674448 ] test_htmlparser.py -- &quot;,&quot; in attributes
Message-ID: <E18dNvf-0000cr-00@sc8-sf-web2.sourceforge.net>

Patches item #674448, was opened at 2003-01-24 23:00
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674448&group_id=5470

>Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
>Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: test_htmlparser.py -- &quot;,&quot; in attributes

Initial Comment:
Added a test verifying patch #669683 works.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=674448&group_id=5470


From noreply@sourceforge.net  Tue Jan 28 05:49:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Mon, 27 Jan 2003 21:49:52 -0800
Subject: [Patches] [ python-Patches-671666 ] Make the default encoding provided on Windows
Message-ID: <E18dOd6-0000M4-00@sc8-sf-web1.sourceforge.net>

Patches item #671666, was opened at 2003-01-21 17:36
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671666&group_id=5470

Category: Library (Lib)
Group: Python 2.3
>Status: Open
Resolution: Rejected
Priority: 5
Submitted By: SUZUKI Hisao (suzuki_hisao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make the default encoding provided on Windows

Initial Comment:
On Windows, some default encodings are not
provided by Python (e.g. "cp932" in Japanese
locale), while they are always available as "mbcs"
in each locale.  This patch ensures them usable in
a very efficient way by aliasing them to "mbcs" in
such a case.

Note that IDLE does not start up on Windows unless
the default encoding is provided.  The patch makes
IDLE operable all over the (Windows) world ;-).

----------------------------------------------------------------------

>Comment By: SUZUKI Hisao (suzuki_hisao)
Date: 2003-01-28 14:49

Message:
Logged In: YES 
user_id=495142

I can reproduce the IDLE problem on my Windows
2000 in Japanese locale.  I hope you will confirm it
by asking your  friends in Japan or other countries.

I am afraid you missed the point.  The patch does NOT change
the default encoding of Python itself.
It is ASCII still.  It only makes the encoding of
locale.getdefaultlocale()[1]  be PROVIDED.

Please read that short patch. 


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 07:04

Message:
Logged In: YES 
user_id=21627

I'm rejecting this patch. The factory system default
encoding of Python is ASCII, on all platforms (atleast, it
should be this way; MacOS currently deviates).

I cannot reproduce the IDLE problem; IDLE starts without
that patch just fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=671666&group_id=5470


From noreply@sourceforge.net  Tue Jan 28 09:16:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 28 Jan 2003 01:16:30 -0800
Subject: [Patches] [ python-Patches-675976 ] mhlib does not obey MHCONTEXT env var
Message-ID: <E18dRr4-0007bt-00@sc8-sf-web1.sourceforge.net>

Patches item #675976, was opened at 2003-01-28 10:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675976&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Nobody/Anonymous (nobody)
Summary: mhlib does not obey MHCONTEXT env var

Initial Comment:
All programs in the (N)MH suite of programs use the
MHCONTEXT environment variable to find the so-called
context file where the current folder is remembered.
mhlib should do the same, so that it can be used in
combination with the standard (N)MH programs.

Also, when writing the context file, mhlib should
replace the Current-Folder line but keep the other
lines in tact.

The attached patch fixes both problems. It introduces a
new method for the class MH called getcontextfile which
uses the MHCONTEXT environment variable to find the
context file, and it uses the already existing function
updateline to update the context file.

Some questions concerning this patch:
- should I document the new method or should it be an
internal method only?
- should the fix be ported to older Python versions?
With the patch it does behave differently if you have
an MHCONTEXT environment variable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675976&group_id=5470


From noreply@sourceforge.net  Tue Jan 28 22:20:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 28 Jan 2003 14:20:26 -0800
Subject: [Patches] [ python-Patches-670664 ] HTMLParser.py - more robust &lt;SCRIPT&gt; parsing
Message-ID: <E18de5i-0008Nc-00@sc8-sf-web2.sourceforge.net>

Patches item #670664, was opened at 2003-01-19 09:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
>Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: HTMLParser.py - more robust &lt;SCRIPT&gt; parsing

Initial Comment:
http://www.ebay.com contains a script element of the form

<SCRIPT>
...
   vbscript += "</SCR"+"IPT> \n";
...
</SCRIPT>

which is not enclosed in "<!-- ... -->" comments.  The parser 
choked on that line, indicating it was a mal-formed end tag.

The changes are:

  interesting_cdata is now a dict mapping start tag to
    an re matching the end tag, a "<--" or \Z

  HTMLParser.set_cdata_mode takes an extra argument, 
    the start tag


----------------------------------------------------------------------

Comment By: j paulson (fantoozler)
Date: 2003-01-24 22:58

Message:
Logged In: YES 
user_id=690612

Found regression test, used it, found error, fixed it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470


From noreply@sourceforge.net  Tue Jan 28 22:20:26 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 28 Jan 2003 14:20:26 -0800
Subject: [Patches] [ python-Patches-669683 ] HTMLParser -- allow &quot;,&quot; in attributes
Message-ID: <E18de5i-0008Ng-00@sc8-sf-web2.sourceforge.net>

Patches item #669683, was opened at 2003-01-17 06:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
>Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: HTMLParser -- allow &quot;,&quot; in attributes

Initial Comment:
An HTML document in the wild had the tag:

<font size="-1" color=rgb(175,18,3)>

and HTMLParser was choking on the "," after the 
"175".  By adding "," to the list of allowed characters 
in attribute values, HTMLParser accepts the document.


----------------------------------------------------------------------

Comment By: j paulson (fantoozler)
Date: 2003-01-24 19:18

Message:
Logged In: YES 
user_id=690612

Added test case to Lib/test/test_htmlparser.py in addition to the 
HTMLParser.py patch

----------------------------------------------------------------------

Comment By: j paulson (fantoozler)
Date: 2003-01-17 13:46

Message:
Logged In: YES 
user_id=690612

I'll attach the patch file again.  

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-17 09:17

Message:
Logged In: YES 
user_id=33168

Was this supposed to be a patch or a bug report?  There is
no patch attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669683&group_id=5470


From noreply@sourceforge.net  Tue Jan 28 22:24:10 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 28 Jan 2003 14:24:10 -0800
Subject: [Patches] [ python-Patches-670664 ] HTMLParser.py - more robust &lt;SCRIPT&gt; parsing
Message-ID: <E18de9K-0005KW-00@sc8-sf-web4.sourceforge.net>

Patches item #670664, was opened at 2003-01-19 09:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser.py - more robust &lt;SCRIPT&gt; parsing

Initial Comment:
http://www.ebay.com contains a script element of the form

<SCRIPT>
...
   vbscript += "</SCR"+"IPT> \n";
...
</SCRIPT>

which is not enclosed in "<!-- ... -->" comments.  The parser 
choked on that line, indicating it was a mal-formed end tag.

The changes are:

  interesting_cdata is now a dict mapping start tag to
    an re matching the end tag, a "<--" or \Z

  HTMLParser.set_cdata_mode takes an extra argument, 
    the start tag


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 17:24

Message:
Logged In: YES 
user_id=3066

>From python-dev:

John Paulson wrote:
>     [...]  A side-effect of this is that
>     any "<!--" .. "-->" within a script/style will
>     be parsed as a comment.  If that behavior is
>     incorrect, the regex can be modified.

Jerry Williams wrote:
Does this mean that the following won't work:

  <SCRIPT language="JavaScript">
    <!-- //
    some-javascript-code
    // -->
  </SCRIPT>

That could be a problem, since this is commonly used
to support browsers that don't understand <SCRIPT>.

See:
http://mail.python.org/pipermail/python-dev/2003-January/032482.html

----------------------------------------------------------------------

Comment By: j paulson (fantoozler)
Date: 2003-01-24 22:58

Message:
Logged In: YES 
user_id=690612

Found regression test, used it, found error, fixed it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470


From noreply@sourceforge.net  Tue Jan 28 22:35:00 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 28 Jan 2003 14:35:00 -0800
Subject: [Patches] [ python-Patches-670664 ] HTMLParser.py - more robust &lt;SCRIPT&gt; parsing
Message-ID: <E18deJo-000588-00@sc8-sf-web1.sourceforge.net>

Patches item #670664, was opened at 2003-01-19 14:07
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j paulson (fantoozler)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser.py - more robust &lt;SCRIPT&gt; parsing

Initial Comment:
http://www.ebay.com contains a script element of the form

<SCRIPT>
...
   vbscript += "</SCR"+"IPT> \n";
...
</SCRIPT>

which is not enclosed in "<!-- ... -->" comments.  The parser 
choked on that line, indicating it was a mal-formed end tag.

The changes are:

  interesting_cdata is now a dict mapping start tag to
    an re matching the end tag, a "<--" or \Z

  HTMLParser.set_cdata_mode takes an extra argument, 
    the start tag


----------------------------------------------------------------------

>Comment By: j paulson (fantoozler)
Date: 2003-01-28 22:35

Message:
Logged In: YES 
user_id=690612

You will get a sequence of:
  handle_starttag("script")
  handle_comment("some-javascript-code")
  handle_endtag("script")

whereas before the sequence was:
  handle_starttag("script")
  handle_data("<!-- ... some-javascript-code ... //-->")
  handle_endtag("script")

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-28 22:24

Message:
Logged In: YES 
user_id=3066

>From python-dev:

John Paulson wrote:
>     [...]  A side-effect of this is that
>     any "<!--" .. "-->" within a script/style will
>     be parsed as a comment.  If that behavior is
>     incorrect, the regex can be modified.

Jerry Williams wrote:
Does this mean that the following won't work:

  <SCRIPT language="JavaScript">
    <!-- //
    some-javascript-code
    // -->
  </SCRIPT>

That could be a problem, since this is commonly used
to support browsers that don't understand <SCRIPT>.

See:
http://mail.python.org/pipermail/python-dev/2003-January/032482.html

----------------------------------------------------------------------

Comment By: j paulson (fantoozler)
Date: 2003-01-25 03:58

Message:
Logged In: YES 
user_id=690612

Found regression test, used it, found error, fixed it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670664&group_id=5470


From noreply@sourceforge.net  Wed Jan 29 00:15:27 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Tue, 28 Jan 2003 16:15:27 -0800
Subject: [Patches] [ python-Patches-676472 ] correct non-blocking behavior in _ssl.c
Message-ID: <E18dft1-0005a0-00@sc8-sf-web2.sourceforge.net>

Patches item #676472, was opened at 2003-01-28 19:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676472&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoff Talvola (gtalvola)
Assigned to: Nobody/Anonymous (nobody)
Summary: correct non-blocking behavior in _ssl.c

Initial Comment:
This is yet another patch to _ssl.c that sets the
underlying BIO to non-blocking if the socket being
wrapped is non-blocking.  It also correctly loops when
SSL_connect, SSL_write, or SSL_read indicates that it
needs to read or write more bytes.

This seems to fix bug #673797 which was not fixed by my
previous patch.

I'm waiting for Ben Laurie to review this patch for me,
then I'll assign it to Guido to check it in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676472&group_id=5470


From noreply@sourceforge.net  Wed Jan 29 15:25:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 29 Jan 2003 07:25:53 -0800
Subject: [Patches] [ python-Patches-676835 ] Cygwin _tkinter Tcl/Tk 8.4 patch
Message-ID: <E18du65-0003SB-00@sc8-sf-web1.sourceforge.net>

Patches item #676835, was opened at 2003-01-29 06:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676835&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: Cygwin _tkinter Tcl/Tk 8.4 patch

Initial Comment:
The (to be) attached patch enables Cygwin Python
to build _tkinter against Tcl/Tk 8.4. Note that this
patch just reverts the lib_prefix (i.e., "cyg") portion
of my Tcl/Tk 8.3 patch. It seems that Cygwin Tcl/Tk
is using a more normal file naming convention again.

----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2003-01-29 06:25

Message:
Logged In: YES 
user_id=86216

Attaching patch to workaround (still?) broken SF.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676835&group_id=5470


From noreply@sourceforge.net  Wed Jan 29 15:24:48 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 29 Jan 2003 07:24:48 -0800
Subject: [Patches] [ python-Patches-676835 ] Cygwin _tkinter Tcl/Tk 8.4 patch
Message-ID: <E18du52-0003Ne-00@sc8-sf-web1.sourceforge.net>

Patches item #676835, was opened at 2003-01-29 06:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676835&group_id=5470

Category: Distutils and setup.py
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: Cygwin _tkinter Tcl/Tk 8.4 patch

Initial Comment:
The (to be) attached patch enables Cygwin Python
to build _tkinter against Tcl/Tk 8.4. Note that this
patch just reverts the lib_prefix (i.e., "cyg") portion
of my Tcl/Tk 8.3 patch. It seems that Cygwin Tcl/Tk
is using a more normal file naming convention again.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676835&group_id=5470


From noreply@sourceforge.net  Wed Jan 29 15:28:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 29 Jan 2003 07:28:52 -0800
Subject: [Patches] [ python-Patches-676837 ] Cygwin array module patch
Message-ID: <E18du8y-0003eS-00@sc8-sf-web1.sourceforge.net>

Patches item #676837, was opened at 2003-01-29 06:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676837&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: Cygwin array module patch

Initial Comment:
The (to be) attached patch enables the array module
to build cleanly under Cygwin again.

----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2003-01-29 06:28

Message:
Logged In: YES 
user_id=86216

Attaching patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676837&group_id=5470


From noreply@sourceforge.net  Wed Jan 29 15:28:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 29 Jan 2003 07:28:01 -0800
Subject: [Patches] [ python-Patches-676837 ] Cygwin array module patch
Message-ID: <E18du89-0003ah-00@sc8-sf-web1.sourceforge.net>

Patches item #676837, was opened at 2003-01-29 06:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676837&group_id=5470

Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: Cygwin array module patch

Initial Comment:
The (to be) attached patch enables the array module
to build cleanly under Cygwin again.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676837&group_id=5470


From noreply@sourceforge.net  Wed Jan 29 15:31:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 29 Jan 2003 07:31:01 -0800
Subject: [Patches] [ python-Patches-676839 ] Cygwin _iconv_codec module patch
Message-ID: <E18duB3-0003mS-00@sc8-sf-web1.sourceforge.net>

Patches item #676839, was opened at 2003-01-29 06:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676839&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: Cygwin _iconv_codec module patch

Initial Comment:
The (to be) attached patch enables the _iconv_codec
module to build cleanly under Cygwin. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676839&group_id=5470


From noreply@sourceforge.net  Wed Jan 29 15:31:54 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 29 Jan 2003 07:31:54 -0800
Subject: [Patches] [ python-Patches-676839 ] Cygwin _iconv_codec module patch
Message-ID: <E18duBu-0003pr-00@sc8-sf-web1.sourceforge.net>

Patches item #676839, was opened at 2003-01-29 06:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676839&group_id=5470

>Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Martin v. Löwis (loewis)
Summary: Cygwin _iconv_codec module patch

Initial Comment:
The (to be) attached patch enables the _iconv_codec
module to build cleanly under Cygwin. 

----------------------------------------------------------------------

>Comment By: Jason Tishler (jlt63)
Date: 2003-01-29 06:31

Message:
Logged In: YES 
user_id=86216

Attaching patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676839&group_id=5470


From noreply@sourceforge.net  Wed Jan 29 22:49:35 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 29 Jan 2003 14:49:35 -0800
Subject: [Patches] [ python-Patches-677103 ] PYTHONBYTECODEBASE patch (PEP 304)
Message-ID: <E18e11T-0000Li-00@sc8-sf-web4.sourceforge.net>

Patches item #677103, was opened at 2003-01-29 16:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: PYTHONBYTECODEBASE patch (PEP 304)

Initial Comment:
This is just a placeholder patch related to PEP 304.  Feel free to
comment on it.  It's far from complete at this point.  The first
patch is just to see if we can do all the proper detection at
startup.  These checks have to be performed before any .py
files are imported, otherwise you'd have some .pyc files dumped
out before the machinery is ready to go.

The first patch contains mods to sysmodule.c with next to
no concern for platform independence.  There is a small shell
script and a few expected output files which are used to
test setting of various values.  These should probably be
wrapped into regular PyUnit tests which popen() the interpreter
with different settings, but this seemed quicker as a start.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470


From noreply@sourceforge.net  Wed Jan 29 22:52:43 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 29 Jan 2003 14:52:43 -0800
Subject: [Patches] [ python-Patches-677103 ] PYTHONBYTECODEBASE patch (PEP 304)
Message-ID: <E18e14V-0000Vl-00@sc8-sf-web4.sourceforge.net>

Patches item #677103, was opened at 2003-01-29 16:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: PYTHONBYTECODEBASE patch (PEP 304)

Initial Comment:
This is just a placeholder patch related to PEP 304.  Feel free to
comment on it.  It's far from complete at this point.  The first
patch is just to see if we can do all the proper detection at
startup.  These checks have to be performed before any .py
files are imported, otherwise you'd have some .pyc files dumped
out before the machinery is ready to go.

The first patch contains mods to sysmodule.c with next to
no concern for platform independence.  There is a small shell
script and a few expected output files which are used to
test setting of various values.  These should probably be
wrapped into regular PyUnit tests which popen() the interpreter
with different settings, but this seemed quicker as a start.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-29 16:52

Message:
Logged In: YES 
user_id=44345

second upload try - what the hell is with SF?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470


From noreply@sourceforge.net  Wed Jan 29 23:11:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 29 Jan 2003 15:11:24 -0800
Subject: [Patches] [ python-Patches-658599 ] Fix for bug 494589
Message-ID: <E18e1Ma-0001cF-00@sc8-sf-web4.sourceforge.net>

Patches item #658599, was opened at 2002-12-26 18:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Mark Hammond (mhammond)
Summary: Fix for bug 494589

Initial Comment:
This is a fix for bug 494589 (os.path.expandvars)
I suggest using the same code in ntpath and posixpath.
(Maybe have a commonpath.py and let both import it?)

Python version 2.2.2
OS: NT4 SP6 (checked on NT and cygwin)

Miki

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2003-01-30 10:11

Message:
Logged In: YES 
user_id=14198

Yes, I was too eager there.

So back to the original patch - it looks good, except it
seems to fail in one case I can see:
$FOO$FOO

is not correctly expanded.  Put a space between the vars, or
enclose them in braces, and it works correctly.

This isn't really a regression though - the old code doesn't
handle that case correctly either.  posixpath does.

See the new patch I uploaded - it contains the original
code, plus a patch to test_ntpath.py to test the semantics.
 Is it possible to fix the patch to handle this case?  I
haven't time to dig out my regex book <wink>

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-17 12:24

Message:
Logged In: YES 
user_id=31435

Did you look at bug 494589?  As I noted there, there are 
semantic diffferences between the ntpath and posixpath 
versions of .expandvars() (like ntpath mapping $$ to $, 
and not expanding within single quotes).

I personally have no use for the differences, but can't say 
whether anyone else does.  The author of the ntpath version 
took time to write comments about its pecularities, so they 
weren't accidents at the time.  Incompatible changes are 
usually PEP material.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-16 16:24

Message:
Logged In: YES 
user_id=14198

It was late last night - the idea of ripping out all
duplicated code wont work.  A consolidation may be possible,
but I haven't time.  I'm deleting that patch, but still
believe that

from posixpath import expandvars

is reasonable.  Comments?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-16 06:14

Message:
Logged In: YES 
user_id=31435

Sounds like an excellent idea to me, Mark!  The glory is all 
yours, if you're man enough to accept it <wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-15 23:38

Message:
Logged In: YES 
user_id=14198

In fact, why not go the whole-hog, and remove all code in
ntpath.py that is identical to posixpath.py

Example patch attached <wink>

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-15 14:44

Message:
Logged In: YES 
user_id=14198

Is there any reason why:

from posixpath import expandvars

is not a better patch?  From what I can see, posixpath's
version works fine for Windows (windows os.environ is case
insensitive)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-14 04:59

Message:
Logged In: YES 
user_id=31435

Mark, can you make time to look at this?  I can't.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-04 14:31

Message:
Logged In: YES 
user_id=33168

The patch didn't apply for me, so I created a new one and
attached it.  I can't test this.  Maybe Tim is interested.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2002-12-29 18:28

Message:
Logged In: YES 
user_id=358087

This time the checkbox is checked. :-)

Miki

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-27 05:07

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470


From noreply@sourceforge.net  Thu Jan 30 01:12:16 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Wed, 29 Jan 2003 17:12:16 -0800
Subject: [Patches] [ python-Patches-625513 ] sets.BaseSet.isdisjointset(other)
Message-ID: <E18e3FY-0000MS-00@sc8-sf-web2.sourceforge.net>

Patches item #625513, was opened at 2002-10-19 00:20
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=625513&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Holloway (shane_holloway)
Assigned to: Nobody/Anonymous (nobody)
Summary: sets.BaseSet.isdisjointset(other)

Initial Comment:
Provides an optimized test for disjoint sets without 
creating an intersection, and returning after finding first 
shared element.


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-01-29 20:12

Message:
Logged In: YES 
user_id=80475

Can this be closed due to lack of interest?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-12-12 18:17

Message:
Logged In: YES 
user_id=80475

Here is an alternative implementation:

>>> def isdisjoint(a,b):
...     return len(a) != len(a|b)

The underlying dict.copy() and dict.update() help give this 
a speed advantage.

----------------------------------------------------------------------

Comment By: Shane Holloway (shane_holloway)
Date: 2002-10-22 13:32

Message:
Logged In: YES 
user_id=283742

I definitely agree that this disjoint set test and an intersection 
both have linear time complexity, but the intersection also 
has a memory complexity that a disjoint test does not have.  
Secondly, in the case of an intersecting set, it short-circuts 
the rest of the loop since it already has the answer, halving 
the time complexity on average.  However, disjoint test 
doesn't benefit from the C-loop of filter that the intersection 
does.

When I wrote this patch, I was creating some large sets 
doing reachability searches, and I wanted to merge the 
intersecting ones.  I started by examining the length of the 
intersection, but the time to allocate the complete result was 
bottlenecking things.  (400K entries.)  Thus I wrote the 
disjoint test and things went much faster.  But, as you said, 
this is neither common nor compelling.  

So I assumed it was a common enough function that others 
would profit from having it the standard library.  It was 
certainly all over my set theory classes a few years ago.  ;)  
Perhaps what we need is more c-loop functions to add to 
map, filter and reduce?  A function called 'first' would work 
wonders here and other places.



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-10-22 00:54

Message:
Logged In: YES 
user_id=80475

In general, I'm a fan of early-out routines, but I agree with 
Tim, unless this patch solves a compelling common case 
and is clear about when and whether it can be used to 
advantage, the filter based itersection method remains the 
best solution for the general case.

Unless a compelling, common use case can be shown, I 
recommend that we don't fatten the interface further.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-10-19 01:33

Message:
Logged In: YES 
user_id=31435

In what sense is this optimized?  People usually 
mean "speed" when they use that word without qualification, 
but this surely runs much slower (most of the time) if the 
sets are in fact disjoint.  OTOH, I'm sure it does run much 
faster (most of the time) if the sets have the same 
elements.

If a method is merely provided for speed in *some* cases, 
it's generally a hard sell.  It would help your case if the 
docs here spelled out exactly when and why someone 
would want to use the new method; else it appears 
mysteriously redundant.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=625513&group_id=5470


From noreply@sourceforge.net  Thu Jan 30 11:30:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 30 Jan 2003 03:30:32 -0800
Subject: [Patches] [ python-Patches-658599 ] Fix for bug 494589
Message-ID: <E18eCts-00048H-00@sc8-sf-web2.sourceforge.net>

Patches item #658599, was opened at 2002-12-26 09:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470

Category: Library (Lib)
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Mark Hammond (mhammond)
Summary: Fix for bug 494589

Initial Comment:
This is a fix for bug 494589 (os.path.expandvars)
I suggest using the same code in ntpath and posixpath.
(Maybe have a commonpath.py and let both import it?)

Python version 2.2.2
OS: NT4 SP6 (checked on NT and cygwin)

Miki

----------------------------------------------------------------------

>Comment By: Miki Tebeka (tebeka)
Date: 2003-01-30 13:30

Message:
Logged In: YES 
user_id=358087

Hopefully this should do the trick (if I'll remember to
attache the file :-)
All I did was to allow a $ only right after the first one.

Miki

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-30 01:11

Message:
Logged In: YES 
user_id=14198

Yes, I was too eager there.

So back to the original patch - it looks good, except it
seems to fail in one case I can see:
$FOO$FOO

is not correctly expanded.  Put a space between the vars, or
enclose them in braces, and it works correctly.

This isn't really a regression though - the old code doesn't
handle that case correctly either.  posixpath does.

See the new patch I uploaded - it contains the original
code, plus a patch to test_ntpath.py to test the semantics.
 Is it possible to fix the patch to handle this case?  I
haven't time to dig out my regex book <wink>

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-17 03:24

Message:
Logged In: YES 
user_id=31435

Did you look at bug 494589?  As I noted there, there are 
semantic diffferences between the ntpath and posixpath 
versions of .expandvars() (like ntpath mapping $$ to $, 
and not expanding within single quotes).

I personally have no use for the differences, but can't say 
whether anyone else does.  The author of the ntpath version 
took time to write comments about its pecularities, so they 
weren't accidents at the time.  Incompatible changes are 
usually PEP material.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-16 07:24

Message:
Logged In: YES 
user_id=14198

It was late last night - the idea of ripping out all
duplicated code wont work.  A consolidation may be possible,
but I haven't time.  I'm deleting that patch, but still
believe that

from posixpath import expandvars

is reasonable.  Comments?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-15 21:14

Message:
Logged In: YES 
user_id=31435

Sounds like an excellent idea to me, Mark!  The glory is all 
yours, if you're man enough to accept it <wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-15 14:38

Message:
Logged In: YES 
user_id=14198

In fact, why not go the whole-hog, and remove all code in
ntpath.py that is identical to posixpath.py

Example patch attached <wink>

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2003-01-15 05:44

Message:
Logged In: YES 
user_id=14198

Is there any reason why:

from posixpath import expandvars

is not a better patch?  From what I can see, posixpath's
version works fine for Windows (windows os.environ is case
insensitive)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-13 19:59

Message:
Logged In: YES 
user_id=31435

Mark, can you make time to look at this?  I can't.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-04 05:31

Message:
Logged In: YES 
user_id=33168

The patch didn't apply for me, so I created a new one and
attached it.  I can't test this.  Maybe Tim is interested.

----------------------------------------------------------------------

Comment By: Miki Tebeka (tebeka)
Date: 2002-12-29 09:28

Message:
Logged In: YES 
user_id=358087

This time the checkbox is checked. :-)

Miki

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-12-26 20:07

Message:
Logged In: YES 
user_id=33168

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470


From noreply@sourceforge.net  Thu Jan 30 11:43:06 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 30 Jan 2003 03:43:06 -0800
Subject: [Patches] [ python-Patches-677429 ] Out of bounds indizes in PEP293 callbacks
Message-ID: <E18eD62-0003Gi-00@sc8-sf-web3.sourceforge.net>

Patches item #677429, was opened at 2003-01-30 12:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677429&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Martin v. Löwis (loewis)
Summary: Out of bounds indizes in PEP293 callbacks

Initial Comment:
This patch changes the treatment of positions returned
by PEP293 error handers in the Unicode codecs: Negative
positions are treated as being relative to the end of
the input and out of bounds positions result in an
IndexError. The patch also updates the PEP and includes
an explanation of this in the documentation for
codecs.register_error. I don't know if this is the best
spot for it, or if it should be put somewhere else.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677429&group_id=5470


From noreply@sourceforge.net  Thu Jan 30 18:26:51 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 30 Jan 2003 10:26:51 -0800
Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv
Message-ID: <E18eJOl-0004r5-00@sc8-sf-web3.sourceforge.net>

Patches item #670715, was opened at 2003-01-19 17:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Martin v. Löwis (loewis)
Summary: Universal Unicode Codec for POSIX iconv

Initial Comment:
Here's the unicode codec using POSIX iconv(3) library.

Tested on these platforms and seems to work:
  FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64,
  FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2

This codec implementation supports PEP293, also.


----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-30 19:26

Message:
Logged In: YES 
user_id=89016

iconvcodec-3.txt does byteswapping under the following
conditions:
    #ifndef WORDS_BIGENDIAN
    #ifdef __GNU_LIBRARY__
Byteswapping is done before encoding to the whole input and
to every piece returned from iconv() for decoding.

Detecting whether byteswapping is neccessary might not work
reliably with the above tests. If this is the case, a test
call to iconv() should probably be done in
Modules/_conv_codec.c::init_iconv_codec() to determine
whether to byte swap or not.

Another possibility might be to use utf-16/utf-32 instead of
ucs-2/ucs-4.

One test still fails: test_sane(), because it uses the
internal encoding in Python, where the real endianness is of
course unknown. The test also assumes a narrow Python build.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-26 16:19

Message:
Logged In: YES 
user_id=55188

Thank you very much for your works.
I'm working on UCS endian detection and UCS transparent 
wrapper for UTF-{8,16}. I'll submit new patch in a week.
Please feel free to change my codes because I'm not familiar 
with python code convention and culture. :-)


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-26 12:32

Message:
Logged In: YES 
user_id=21627

I have committed it now with minimal changes so that it
works on Linux, as

setup.py 1.138
__init__.py 1.15
iconv_codec.py 1.1
regrtest.py 1.117
NEWS 1.627

I will make further changes; please watch the CVS. If you
would like to make further changes, please submit patches
against the CVS.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 02:07

Message:
Logged In: YES 
user_id=21627

Hmm. I see that Solaris does support conversion of CJK to
UTF-8. So even though we cannot convert into the internal
encoding, we could still convert through UTF-8.

Looking at /usr/lib/nls/iconv/config.iconv of HP-UX 11.11, I
see conversions from and to ucs2, for iso-8859, eucJP, sjis,
eucTW, big5, roc15, kore5, hp15CN, and many IBM code pages.

So I think the iconv codec should convert into the Python
internal representation if possible. If no encoding name for
that is known, it should convert to ucs2 (be) if possible,
or else to UTF-8; in all cases, it will then construct a
Unicode object from the resulting string.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-22 01:21

Message:
Logged In: YES 
user_id=55188

iconv implementations on commercial UNIXes are very scary. 

Solaris implementation:
  no support for CJK <-> UCS conversion.
  They support UCS[24] only for iso-8859 and UTFs.

HP-UX implementation:
  They have useless iconv. HP-UX iconv has no unicode support.

BSD implementation (Konstantin Chuguev's):
  compatible with this patch (provides ucs-[24]-internal)

GLIBC implementation:
  provides ucs-[24] and they are same with GNU iconv's
ucs-[24]-internal.
  Because ucs-[24] of GNU/BSD implentation is big endian
always. We can't use ucs-[24] for every platform.

In conclusion, we must use 3rd party iconv on Solaris or HP-UX.
And, we need to detect whether the linked iconv is GNU/BSD
iconv or GLIBC iconv. (how?)

I'll investigate how to detect them, but ... :)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 23:27

Message:
Logged In: YES 
user_id=21627

I'm quite happy with this patch, and will apply it shortly.
However, I am concerned that it is specific for GNU iconv.
IMO, there should be machinery to find out the "internal"
encoding, in case native the native iconv implementation is
used instead of GNU iconv.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-20 14:33

Message:
Logged In: YES 
user_id=55188

Thank you for comments. :->
I uploaded a new revised patch with unittest and some code
style fixes.

I saw Martin v. Loewis's iconvcodecs about a years ago.
His implementation is very neat, but it had a limit on error
handling due to recursive call.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-19 23:56

Message:
Logged In: YES 
user_id=38388

The patch looks good, but you'll need to add some form
of testing to underline the "seems to work" :-)

Some docs on how to use the codec would also be needed.

Martin von Loewis has written a similar codec some months ago.
Perhaps you two could get in touch and sort out the details ?!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470


From noreply@sourceforge.net  Thu Jan 30 20:04:04 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 30 Jan 2003 12:04:04 -0800
Subject: [Patches] [ python-Patches-670715 ] Universal Unicode Codec for POSIX iconv
Message-ID: <E18eKuq-00085k-00@sc8-sf-web4.sourceforge.net>

Patches item #670715, was opened at 2003-01-19 17:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Martin v. Löwis (loewis)
Summary: Universal Unicode Codec for POSIX iconv

Initial Comment:
Here's the unicode codec using POSIX iconv(3) library.

Tested on these platforms and seems to work:
  FreeBSD/i386, FreeBSD/alpha, FreeBSD/ia64,
  FreeBSD/sparc64, MacOS X/ppc, HP-UX/pa-risc2

This codec implementation supports PEP293, also.


----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-30 21:04

Message:
Logged In: YES 
user_id=89016

I checked in a version of iconvcodec-3.txt that does a byte
swapping check in the init function as
Modules/_iconv_codec.c 1.5

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-30 19:26

Message:
Logged In: YES 
user_id=89016

iconvcodec-3.txt does byteswapping under the following
conditions:
    #ifndef WORDS_BIGENDIAN
    #ifdef __GNU_LIBRARY__
Byteswapping is done before encoding to the whole input and
to every piece returned from iconv() for decoding.

Detecting whether byteswapping is neccessary might not work
reliably with the above tests. If this is the case, a test
call to iconv() should probably be done in
Modules/_conv_codec.c::init_iconv_codec() to determine
whether to byte swap or not.

Another possibility might be to use utf-16/utf-32 instead of
ucs-2/ucs-4.

One test still fails: test_sane(), because it uses the
internal encoding in Python, where the real endianness is of
course unknown. The test also assumes a narrow Python build.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-26 16:19

Message:
Logged In: YES 
user_id=55188

Thank you very much for your works.
I'm working on UCS endian detection and UCS transparent 
wrapper for UTF-{8,16}. I'll submit new patch in a week.
Please feel free to change my codes because I'm not familiar 
with python code convention and culture. :-)


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-26 12:32

Message:
Logged In: YES 
user_id=21627

I have committed it now with minimal changes so that it
works on Linux, as

setup.py 1.138
__init__.py 1.15
iconv_codec.py 1.1
regrtest.py 1.117
NEWS 1.627

I will make further changes; please watch the CVS. If you
would like to make further changes, please submit patches
against the CVS.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-22 02:07

Message:
Logged In: YES 
user_id=21627

Hmm. I see that Solaris does support conversion of CJK to
UTF-8. So even though we cannot convert into the internal
encoding, we could still convert through UTF-8.

Looking at /usr/lib/nls/iconv/config.iconv of HP-UX 11.11, I
see conversions from and to ucs2, for iso-8859, eucJP, sjis,
eucTW, big5, roc15, kore5, hp15CN, and many IBM code pages.

So I think the iconv codec should convert into the Python
internal representation if possible. If no encoding name for
that is known, it should convert to ucs2 (be) if possible,
or else to UTF-8; in all cases, it will then construct a
Unicode object from the resulting string.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-22 01:21

Message:
Logged In: YES 
user_id=55188

iconv implementations on commercial UNIXes are very scary. 

Solaris implementation:
  no support for CJK <-> UCS conversion.
  They support UCS[24] only for iso-8859 and UTFs.

HP-UX implementation:
  They have useless iconv. HP-UX iconv has no unicode support.

BSD implementation (Konstantin Chuguev's):
  compatible with this patch (provides ucs-[24]-internal)

GLIBC implementation:
  provides ucs-[24] and they are same with GNU iconv's
ucs-[24]-internal.
  Because ucs-[24] of GNU/BSD implentation is big endian
always. We can't use ucs-[24] for every platform.

In conclusion, we must use 3rd party iconv on Solaris or HP-UX.
And, we need to detect whether the linked iconv is GNU/BSD
iconv or GLIBC iconv. (how?)

I'll investigate how to detect them, but ... :)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-21 23:27

Message:
Logged In: YES 
user_id=21627

I'm quite happy with this patch, and will apply it shortly.
However, I am concerned that it is specific for GNU iconv.
IMO, there should be machinery to find out the "internal"
encoding, in case native the native iconv implementation is
used instead of GNU iconv.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2003-01-20 14:33

Message:
Logged In: YES 
user_id=55188

Thank you for comments. :->
I uploaded a new revised patch with unittest and some code
style fixes.

I saw Martin v. Loewis's iconvcodecs about a years ago.
His implementation is very neat, but it had a limit on error
handling due to recursive call.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-19 23:56

Message:
Logged In: YES 
user_id=38388

The patch looks good, but you'll need to add some form
of testing to underline the "seems to work" :-)

Some docs on how to use the codec would also be needed.

Martin von Loewis has written a similar codec some months ago.
Perhaps you two could get in touch and sort out the details ?!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=670715&group_id=5470


From noreply@sourceforge.net  Thu Jan 30 20:33:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 30 Jan 2003 12:33:50 -0800
Subject: [Patches] [ python-Patches-677719 ] improved readline usage in pdb
Message-ID: <E18eLNe-0005ZE-00@sc8-sf-web2.sourceforge.net>

Patches item #677719, was opened at 2003-01-30 20:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677719&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Stone (mbrierst)
Assigned to: Nobody/Anonymous (nobody)
Summary: improved readline usage in pdb

Initial Comment:

Adds tab-completion of locals and globals in the scope of the code being executed by pdb from the (Pdb) prompt.

patchrlcomplete:
* adds a local namespace to the arguments of Completer's constructor.  Necessary to evaluate local objects correctly when doing completion.  Defaults to None so backwards compatibility should be fine.
* No longer always loads the Completer on import.  Only loads it when a completer has not been assigned.  This is better if someone has previously loaded a completer they don't want changed.  Without this the pdb completer would have to save the old completer before importing the rlcompleter module to avoid the undesired side effect of pdb changing the completion function.
* removes words.append('__class__') as it should already be included.  I'm not sure if there's a good reason for this line.  It was originally written by Michael Hudson I believe, perhaps he knows if there is someplace this does something?  (this has nothing to do with the main work of this patch)
* allows __builtins__ to be completed like anything else.  Why not?  Sometimes I want to look at __builtins__.  Is there a reason not to allow it to be completed?  (again, nothing to do with the main patch)

patchpdb:
* complete method overrides Cmd's complete method.  Gives all completions from Cmd.complete followed by completions from rl_completer.

Let me know what you think of it (the idea and the implementation).  If you don't want my small irrelevant changes to rlcompleter, I can get rid of them.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677719&group_id=5470


From noreply@sourceforge.net  Thu Jan 30 22:33:18 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 30 Jan 2003 14:33:18 -0800
Subject: [Patches] [ python-Patches-677103 ] PYTHONBYTECODEBASE patch (PEP 304)
Message-ID: <E18eNFG-0007cA-00@sc8-sf-web4.sourceforge.net>

Patches item #677103, was opened at 2003-01-29 16:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: PYTHONBYTECODEBASE patch (PEP 304)

Initial Comment:
This is just a placeholder patch related to PEP 304.  Feel free to
comment on it.  It's far from complete at this point.  The first
patch is just to see if we can do all the proper detection at
startup.  These checks have to be performed before any .py
files are imported, otherwise you'd have some .pyc files dumped
out before the machinery is ready to go.

The first patch contains mods to sysmodule.c with next to
no concern for platform independence.  There is a small shell
script and a few expected output files which are used to
test setting of various values.  These should probably be
wrapped into regular PyUnit tests which popen() the interpreter
with different settings, but this seemed quicker as a start.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-30 16:33

Message:
Logged In: YES 
user_id=44345

Here's an updated context diff.  It seems to do the right thing on my
Mac OS X system.  It won't currently do anything on Windows ( need help
there).  No more test cases, but if PYTHONBYTECODEBASE points to
a valid directory, the .pyc files seem to get put in all the right places.

To get the behavior, you'll have to configure --with-bytecodebase.

Feedback, please...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-29 16:52

Message:
Logged In: YES 
user_id=44345

second upload try - what the hell is with SF?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470


From noreply@sourceforge.net  Thu Jan 30 22:51:53 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 30 Jan 2003 14:51:53 -0800
Subject: [Patches] [ python-Patches-677103 ] PYTHONBYTECODEBASE patch (PEP 304)
Message-ID: <E18eNXF-0008Cp-00@sc8-sf-web4.sourceforge.net>

Patches item #677103, was opened at 2003-01-29 16:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: PYTHONBYTECODEBASE patch (PEP 304)

Initial Comment:
This is just a placeholder patch related to PEP 304.  Feel free to
comment on it.  It's far from complete at this point.  The first
patch is just to see if we can do all the proper detection at
startup.  These checks have to be performed before any .py
files are imported, otherwise you'd have some .pyc files dumped
out before the machinery is ready to go.

The first patch contains mods to sysmodule.c with next to
no concern for platform independence.  There is a small shell
script and a few expected output files which are used to
test setting of various values.  These should probably be
wrapped into regular PyUnit tests which popen() the interpreter
with different settings, but this seemed quicker as a start.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-30 16:51

Message:
Logged In: YES 
user_id=44345

While not technically broken, the patch I just posted is a bit bent.
Withdrawing for a little fixup...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-30 16:33

Message:
Logged In: YES 
user_id=44345

Here's an updated context diff.  It seems to do the right thing on my
Mac OS X system.  It won't currently do anything on Windows ( need help
there).  No more test cases, but if PYTHONBYTECODEBASE points to
a valid directory, the .pyc files seem to get put in all the right places.

To get the behavior, you'll have to configure --with-bytecodebase.

Feedback, please...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-29 16:52

Message:
Logged In: YES 
user_id=44345

second upload try - what the hell is with SF?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470


From noreply@sourceforge.net  Thu Jan 30 23:11:44 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 30 Jan 2003 15:11:44 -0800
Subject: [Patches] [ python-Patches-677838 ] python-mode.el: make "C-c -" work correctly after "C-c |"
Message-ID: <E18eNqS-0000Yi-00@sc8-sf-web1.sourceforge.net>

Patches item #677838, was opened at 2003-01-30 23:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles G Waldman (cgw)
Assigned to: Nobody/Anonymous (nobody)
Summary: python-mode.el: make "C-c -" work correctly after "C-c |"

Initial Comment:

If you are using python-mode in [X]Emacs and do
py-execute-region and get an exception, py-up-exception
(C-c -) will go to the wrong line, because the line
number reported by Python is only relative to the start
of the region.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470


From noreply@sourceforge.net  Thu Jan 30 23:19:29 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 30 Jan 2003 15:19:29 -0800
Subject: [Patches] [ python-Patches-677838 ] python-mode.el: make &quot;C-c -&quot; work correctly after &quot;C-c |&quot;
Message-ID: <E18eNxx-0000vB-00@sc8-sf-web4.sourceforge.net>

Patches item #677838, was opened at 2003-01-30 23:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470

>Category: Demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles G Waldman (cgw)
>Assigned to: Barry A. Warsaw (bwarsaw)
>Summary: python-mode.el: make &quot;C-c -&quot; work correctly after &quot;C-c |&quot;

Initial Comment:

If you are using python-mode in [X]Emacs and do
py-execute-region and get an exception, py-up-exception
(C-c -) will go to the wrong line, because the line
number reported by Python is only relative to the start
of the region.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 01:10:59 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 30 Jan 2003 17:10:59 -0800
Subject: [Patches] [ python-Patches-677887 ] Add traceback.format_exc
Message-ID: <E18ePhr-00052P-00@sc8-sf-web4.sourceforge.net>

Patches item #677887, was opened at 2003-01-31 01:10
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Add traceback.format_exc

Initial Comment:
I sometimes end up wanting this function.  I think it
compliments
print_exc() nicely.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677887&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 01:28:05 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 30 Jan 2003 17:28:05 -0800
Subject: [Patches] [ python-Patches-677890 ] add optional CWD argument to os.path.abspath()
Message-ID: <E18ePyP-0004D8-00@sc8-sf-web1.sourceforge.net>

Patches item #677890, was opened at 2003-01-30 20:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Klanderman (gregklanderman)
Assigned to: Nobody/Anonymous (nobody)
Summary: add optional CWD argument to os.path.abspath()

Initial Comment:
I would like to add an optional second argument to
os.path.abspath() to allow specifying the directory
with respect to which the path should be made
absolute.  This would be much like the optional second
argument of the expand-file-name function in emacs:

(expand-file-name NAME &optional DEFAULT-DIRECTORY)

The patch is against python 2.2.2.  I am running RH 6.3
linux 
but that should not matter.

thanks
Greg Klanderman
gak@klanderman.net


----------------------------------------------------------------------

>Comment By: Greg Klanderman (gregklanderman)
Date: 2003-01-30 20:28

Message:
Logged In: YES 
user_id=698972

sorry, trying again to attach the patch..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 01:23:08 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Thu, 30 Jan 2003 17:23:08 -0800
Subject: [Patches] [ python-Patches-677890 ] add optional CWD argument to os.path.abspath()
Message-ID: <E18ePtc-0005OI-00@sc8-sf-web4.sourceforge.net>

Patches item #677890, was opened at 2003-01-30 20:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470

Category: Library (Lib)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Klanderman (gregklanderman)
Assigned to: Nobody/Anonymous (nobody)
Summary: add optional CWD argument to os.path.abspath()

Initial Comment:
I would like to add an optional second argument to
os.path.abspath() to allow specifying the directory
with respect to which the path should be made
absolute.  This would be much like the optional second
argument of the expand-file-name function in emacs:

(expand-file-name NAME &optional DEFAULT-DIRECTORY)

The patch is against python 2.2.2.  I am running RH 6.3
linux 
but that should not matter.

thanks
Greg Klanderman
gak@klanderman.net


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 13:16:01 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 05:16:01 -0800
Subject: [Patches] [ python-Patches-677838 ] python-mode.el: make &quot;C-c -&quot; work correctly after
Message-ID: <E18eb1V-0003P5-00@sc8-sf-web4.sourceforge.net>

Patches item #677838, was opened at 2003-01-30 23:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470

Category: Demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles G Waldman (cgw)
Assigned to: Barry A. Warsaw (bwarsaw)
>Summary: python-mode.el: make &quot;C-c -&quot; work correctly after 

Initial Comment:

If you are using python-mode in [X]Emacs and do
py-execute-region and get an exception, py-up-exception
(C-c -) will go to the wrong line, because the line
number reported by Python is only relative to the start
of the region.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2003-01-31 13:16

Message:
Logged In: YES 
user_id=6656

There's no patch attached... I think SF is subliminally
trying to push us into getting roundup ready to use.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 15:23:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 07:23:37 -0800
Subject: [Patches] [ python-Patches-677429 ] Out of bounds indizes in PEP293 callbacks
Message-ID: <E18ed0z-0006xs-00@sc8-sf-web1.sourceforge.net>

Patches item #677429, was opened at 2003-01-30 06:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677429&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: Out of bounds indizes in PEP293 callbacks

Initial Comment:
This patch changes the treatment of positions returned
by PEP293 error handers in the Unicode codecs: Negative
positions are treated as being relative to the end of
the input and out of bounds positions result in an
IndexError. The patch also updates the PEP and includes
an explanation of this in the documentation for
codecs.register_error. I don't know if this is the best
spot for it, or if it should be put somewhere else.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-31 10:23

Message:
Logged In: YES 
user_id=6380

Since this says "codec" I've assigned it to Marc-Andre. :-)

Marc-Andre, if you don't have time, feel free to unassign it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677429&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 15:46:46 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 07:46:46 -0800
Subject: [Patches] [ python-Patches-677429 ] Out of bounds indizes in PEP293 callbacks
Message-ID: <E18edNO-0008Ey-00@sc8-sf-web1.sourceforge.net>

Patches item #677429, was opened at 2003-01-30 12:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677429&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: Walter Dörwald (doerwalter)
Summary: Out of bounds indizes in PEP293 callbacks

Initial Comment:
This patch changes the treatment of positions returned
by PEP293 error handers in the Unicode codecs: Negative
positions are treated as being relative to the end of
the input and out of bounds positions result in an
IndexError. The patch also updates the PEP and includes
an explanation of this in the documentation for
codecs.register_error. I don't know if this is the best
spot for it, or if it should be put somewhere else.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-31 16:46

Message:
Logged In: YES 
user_id=38388

... and I thought Unicode was the keyword ;-)

I fully trust Walter on the error handler callbacks, so I'll
pass it on to him.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-31 16:23

Message:
Logged In: YES 
user_id=6380

Since this says "codec" I've assigned it to Marc-Andre. :-)

Marc-Andre, if you don't have time, feel free to unassign it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677429&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 16:37:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 08:37:03 -0800
Subject: [Patches] [ python-Patches-677838 ] python-mode.el: make C-c - work correctly after C-c |
Message-ID: <E18eeA3-0003iu-00@sc8-sf-web4.sourceforge.net>

Patches item #677838, was opened at 2003-01-30 23:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470

Category: Demos and tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles G Waldman (cgw)
Assigned to: Barry A. Warsaw (bwarsaw)
>Summary: python-mode.el: make C-c - work correctly after C-c |

Initial Comment:

If you are using python-mode in [X]Emacs and do
py-execute-region and get an exception, py-up-exception
(C-c -) will go to the wrong line, because the line
number reported by Python is only relative to the start
of the region.


----------------------------------------------------------------------

>Comment By: Charles G Waldman (cgw)
Date: 2003-01-31 16:37

Message:
Logged In: YES 
user_id=7151

I tried uploading the patch again,  and seem to have
succeeded this
time around.  It's probably not fair to blane SF, as I think
this was a case of pilot error.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-31 13:16

Message:
Logged In: YES 
user_id=6656

There's no patch attached... I think SF is subliminally
trying to push us into getting roundup ready to use.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677838&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 16:39:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 08:39:36 -0800
Subject: [Patches] [ python-Patches-678211 ] buildpkg.py fixes for finding resources
Message-ID: <E18eeCW-0002wL-00@sc8-sf-web1.sourceforge.net>

Patches item #678211, was opened at 2003-01-31 08:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678211&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Dunn (robind)
Assigned to: Jack Jansen (jackjansen)
Summary: buildpkg.py fixes for finding resources

Initial Comment:
Mac/scripts.buildpkg.py has some incorrect code for
finding and building the installer resources, at least
I couldn't get it to work as-is and it didn't quite
match some docs I found.  This patch fixes the
isntallation of the various pre/post scripts and also
adds the ability to use the RootVolumeOnly directive.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678211&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 16:44:03 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 08:44:03 -0800
Subject: [Patches] [ python-Patches-678218 ] Adds icon support to bundlebuilder.py
Message-ID: <E18eeGp-0003x3-00@sc8-sf-web4.sourceforge.net>

Patches item #678218, was opened at 2003-01-31 08:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678218&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Dunn (robind)
Assigned to: Jack Jansen (jackjansen)
Summary: Adds icon support to bundlebuilder.py

Initial Comment:
This patch adds support for an --iconfile parameter and
etc. to bundlebuilder.py and if given will copy the
given icon file to the bundle's resources and will set
the CFBundleIconFile value in the plist file.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678218&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 17:29:23 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 09:29:23 -0800
Subject: [Patches] [ python-Patches-677429 ] Out of bounds indizes in PEP293 callbacks
Message-ID: <E18eeyh-0006hn-00@sc8-sf-web3.sourceforge.net>

Patches item #677429, was opened at 2003-01-30 12:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677429&group_id=5470

Category: None
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Walter Dörwald (doerwalter)
Summary: Out of bounds indizes in PEP293 callbacks

Initial Comment:
This patch changes the treatment of positions returned
by PEP293 error handers in the Unicode codecs: Negative
positions are treated as being relative to the end of
the input and out of bounds positions result in an
IndexError. The patch also updates the PEP and includes
an explanation of this in the documentation for
codecs.register_error. I don't know if this is the best
spot for it, or if it should be put somewhere else.

----------------------------------------------------------------------

>Comment By: Walter Dörwald (doerwalter)
Date: 2003-01-31 18:29

Message:
Logged In: YES 
user_id=89016

Checked in as:
Doc/lib/libcodecs.tex 1.17
Doc/lib/libfuncs.tex 1.128
Lib/test/test_codeccallbacks.py 1.9
Modules/_iconv_codec.c 1.7
Objects/unicodeobject.c 2.180
nondist/peps/pep-0293.txt 1.7

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-31 16:46

Message:
Logged In: YES 
user_id=38388

... and I thought Unicode was the keyword ;-)

I fully trust Walter on the error handler callbacks, so I'll
pass it on to him.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-31 16:23

Message:
Logged In: YES 
user_id=6380

Since this says "codec" I've assigned it to Marc-Andre. :-)

Marc-Andre, if you don't have time, feel free to unassign it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677429&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 17:37:02 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 09:37:02 -0800
Subject: [Patches] [ python-Patches-677103 ] PYTHONBYTECODEBASE patch (PEP 304)
Message-ID: <E18ef66-0006EB-00@sc8-sf-web4.sourceforge.net>

Patches item #677103, was opened at 2003-01-29 16:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: PYTHONBYTECODEBASE patch (PEP 304)

Initial Comment:
This is just a placeholder patch related to PEP 304.  Feel free to
comment on it.  It's far from complete at this point.  The first
patch is just to see if we can do all the proper detection at
startup.  These checks have to be performed before any .py
files are imported, otherwise you'd have some .pyc files dumped
out before the machinery is ready to go.

The first patch contains mods to sysmodule.c with next to
no concern for platform independence.  There is a small shell
script and a few expected output files which are used to
test setting of various values.  These should probably be
wrapped into regular PyUnit tests which popen() the interpreter
with different settings, but this seemed quicker as a start.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-01-31 11:37

Message:
Logged In: YES 
user_id=44345

Another patch.  This one fixes the problems of the one I withdrew yesterday.
There are still problems:

* A half dozen regression tests fail for various reasons which I haven't
completely investigated.

* Nothing has been done for Windows.  Someone will have to step up to
the plate for this.  I can't build on Windows.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-30 16:51

Message:
Logged In: YES 
user_id=44345

While not technically broken, the patch I just posted is a bit bent.
Withdrawing for a little fixup...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-30 16:33

Message:
Logged In: YES 
user_id=44345

Here's an updated context diff.  It seems to do the right thing on my
Mac OS X system.  It won't currently do anything on Windows ( need help
there).  No more test cases, but if PYTHONBYTECODEBASE points to
a valid directory, the .pyc files seem to get put in all the right places.

To get the behavior, you'll have to configure --with-bytecodebase.

Feedback, please...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-29 16:52

Message:
Logged In: YES 
user_id=44345

second upload try - what the hell is with SF?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 17:53:30 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 09:53:30 -0800
Subject: [Patches] [ python-Patches-676472 ] correct non-blocking behavior in _ssl.c
Message-ID: <E18efM2-0000au-00@sc8-sf-web2.sourceforge.net>

Patches item #676472, was opened at 2003-01-28 19:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676472&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoff Talvola (gtalvola)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: correct non-blocking behavior in _ssl.c

Initial Comment:
This is yet another patch to _ssl.c that sets the
underlying BIO to non-blocking if the socket being
wrapped is non-blocking.  It also correctly loops when
SSL_connect, SSL_write, or SSL_read indicates that it
needs to read or write more bytes.

This seems to fix bug #673797 which was not fixed by my
previous patch.

I'm waiting for Ben Laurie to review this patch for me,
then I'll assign it to Guido to check it in.

----------------------------------------------------------------------

>Comment By: Geoff Talvola (gtalvola)
Date: 2003-01-31 12:53

Message:
Logged In: YES 
user_id=88162

Reviewed by Ben Laurie, ready to check in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676472&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 17:57:36 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 09:57:36 -0800
Subject: [Patches] [ python-Patches-678257 ] fix for socket.sendall() with timeout
Message-ID: <E18efQ0-0007JV-00@sc8-sf-web1.sourceforge.net>

Patches item #678257, was opened at 2003-01-31 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678257&group_id=5470

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoff Talvola (gtalvola)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for socket.sendall() with timeout

Initial Comment:
The way socket.sendall is coded now, if there's a
timeout set on the socket, and you're trying to send 2
bytes, and only one byte is able to be sent
immediately, you'll get one byte sent, then it'll loop
back around and an immediate error will occur without
waiting for the full timeout period.

Moving the internal_select() into the do-while loop
fixes the problem.  See the attached patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678257&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 18:21:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 10:21:39 -0800
Subject: [Patches] [ python-Patches-678257 ] fix for socket.sendall() with timeout
Message-ID: <E18efnH-0008Lt-00@sc8-sf-web1.sourceforge.net>

Patches item #678257, was opened at 2003-01-31 12:57
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678257&group_id=5470

Category: Modules
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Geoff Talvola (gtalvola)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for socket.sendall() with timeout

Initial Comment:
The way socket.sendall is coded now, if there's a
timeout set on the socket, and you're trying to send 2
bytes, and only one byte is able to be sent
immediately, you'll get one byte sent, then it'll loop
back around and an immediate error will occur without
waiting for the full timeout period.

Moving the internal_select() into the do-while loop
fixes the problem.  See the attached patch.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-31 13:21

Message:
Logged In: YES 
user_id=6380

Thanks. Checked in as socketmodule.c rev 1.252.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678257&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 18:23:39 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 10:23:39 -0800
Subject: [Patches] [ python-Patches-676472 ] correct non-blocking behavior in _ssl.c
Message-ID: <E18efpD-0002Cj-00@sc8-sf-web2.sourceforge.net>

Patches item #676472, was opened at 2003-01-28 19:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676472&group_id=5470

Category: Modules
Group: Python 2.3
Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Geoff Talvola (gtalvola)
Assigned to: Guido van Rossum (gvanrossum)
Summary: correct non-blocking behavior in _ssl.c

Initial Comment:
This is yet another patch to _ssl.c that sets the
underlying BIO to non-blocking if the socket being
wrapped is non-blocking.  It also correctly loops when
SSL_connect, SSL_write, or SSL_read indicates that it
needs to read or write more bytes.

This seems to fix bug #673797 which was not fixed by my
previous patch.

I'm waiting for Ben Laurie to review this patch for me,
then I'll assign it to Guido to check it in.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-31 13:18

Message:
Logged In: YES 
user_id=6380

OK, checked in as _ssl.c 1.10. Thanks to both of you!

----------------------------------------------------------------------

Comment By: Geoff Talvola (gtalvola)
Date: 2003-01-31 12:53

Message:
Logged In: YES 
user_id=88162

Reviewed by Ben Laurie, ready to check in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676472&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 18:18:50 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 10:18:50 -0800
Subject: [Patches] [ python-Patches-676472 ] correct non-blocking behavior in _ssl.c
Message-ID: <E18efkY-0008Bb-00@sc8-sf-web1.sourceforge.net>

Patches item #676472, was opened at 2003-01-28 19:15
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676472&group_id=5470

Category: Modules
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Geoff Talvola (gtalvola)
Assigned to: Guido van Rossum (gvanrossum)
Summary: correct non-blocking behavior in _ssl.c

Initial Comment:
This is yet another patch to _ssl.c that sets the
underlying BIO to non-blocking if the socket being
wrapped is non-blocking.  It also correctly loops when
SSL_connect, SSL_write, or SSL_read indicates that it
needs to read or write more bytes.

This seems to fix bug #673797 which was not fixed by my
previous patch.

I'm waiting for Ben Laurie to review this patch for me,
then I'll assign it to Guido to check it in.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-31 13:18

Message:
Logged In: YES 
user_id=6380

OK, checked in as _ssl.c 1.10. Thanks to both of you!

----------------------------------------------------------------------

Comment By: Geoff Talvola (gtalvola)
Date: 2003-01-31 12:53

Message:
Logged In: YES 
user_id=88162

Reviewed by Ben Laurie, ready to check in.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=676472&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 20:12:32 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 12:12:32 -0800
Subject: [Patches] [ python-Patches-608182 ] Enhanced file constructor
Message-ID: <E18ehWa-0007kS-00@sc8-sf-web2.sourceforge.net>

Patches item #608182, was opened at 2002-09-11 22:45
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Taral (taral)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhanced file constructor

Initial Comment:
This patch allows the file constructor to take a file
descriptor, allowing for  much easier extension of its
functionality.

----------------------------------------------------------------------

>Comment By: Taral (taral)
Date: 2003-01-31 14:12

Message:
Logged In: YES 
user_id=25129

Didn't make it into 2.3alpha?

----------------------------------------------------------------------

Comment By: Taral (taral)
Date: 2002-09-12 13:39

Message:
Logged In: YES 
user_id=25129

class some_class(file):
    def __init__(self, arg):
        fd = do_some_os_stuff_with_forks_and_pipes_or_sockets
        return file.__init__(self, fd, 'r')

    def close(self):
        do_some_cleanup_stuff
        return file.close(self)

and so on.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-09-12 01:59

Message:
Logged In: YES 
user_id=21627

What's wrong with os.fdopen? Why is

f = file(10, "r")

much easier than

f = os.fdopen(10, "r")

----------------------------------------------------------------------

Comment By: Taral (taral)
Date: 2002-09-12 00:31

Message:
Logged In: YES 
user_id=25129

Okay, fixed it all. Passes 'make test' on linux/x86 with
default configure (does not test dbm/gdbm/mpz/bsddb).

(btw, old versions can be deleted)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-09-11 23:10

Message:
Logged In: YES 
user_id=33168

fp's and fd's are not interchangable.  The variable should
be called fd, since it's an int.  fill_file_fields() 2nd arg
is a FILE*, not an int.  So you would need to do file =
fdopen(fd, mode), then pass file as the 2nd arg.  In order
for this patch to be accepted, a test would also need to be
added (see Lib/test/test_file.py) and doc should be updated
(see Doc/lib/libfuncs.tex).

----------------------------------------------------------------------

Comment By: Taral (taral)
Date: 2002-09-11 22:47

Message:
Logged In: YES 
user_id=25129

Bah, forgot the variable.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 20:52:52 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 12:52:52 -0800
Subject: [Patches] [ python-Patches-669198 ] Add cflags to RC compile
Message-ID: <E18ei9c-0007Q9-00@sc8-sf-web1.sourceforge.net>

Patches item #669198, was opened at 2003-01-16 19:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669198&group_id=5470

Category: Distutils and setup.py
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Robin Dunn (robind)
>Assigned to: Thomas Heller (theller)
Summary: Add cflags to RC compile

Initial Comment:
wxPython's setup.py needs to give the -I flags to the
rc.exe command so the #include in the .rc file can find
the specified file.  This little one line change to
msvccompiler.py adds all the -I and -D flags used for
the C compiler to the RC compiler as well, and solves
wxPython's problem.

BTW, this is the last distutils thing that I have to
workaround in wxPython's setup.py.  With the distutils
in 2.3 I will be able to remove all my other hacks.  If
this patch makes it in the final then they will all be
gone.



----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2003-01-31 21:52

Message:
Logged In: YES 
user_id=11105

This looks good. Checked in, and closed.
Thanks for the patch, Robin, looking forward to build 
wxPython myself ;-)

----------------------------------------------------------------------

Comment By: Robin Dunn (robind)
Date: 2003-01-16 19:18

Message:
Logged In: YES 
user_id=53955

attached patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=669198&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 23:21:37 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 15:21:37 -0800
Subject: [Patches] [ python-Patches-678211 ] buildpkg.py fixes for finding resources
Message-ID: <E18ekTZ-00072O-00@sc8-sf-web2.sourceforge.net>

Patches item #678211, was opened at 2003-01-31 17:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678211&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Dunn (robind)
>Assigned to: Just van Rossum (jvr)
Summary: buildpkg.py fixes for finding resources

Initial Comment:
Mac/scripts.buildpkg.py has some incorrect code for
finding and building the installer resources, at least
I couldn't get it to work as-is and it didn't quite
match some docs I found.  This patch fixes the
isntallation of the various pre/post scripts and also
adds the ability to use the RootVolumeOnly directive.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-02-01 00:21

Message:
Logged In: YES 
user_id=45365

This is Just's, and I haven't looked at it at all yet, so I'm reassiging to him.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678211&group_id=5470


From noreply@sourceforge.net  Fri Jan 31 23:22:24 2003
From: noreply@sourceforge.net (SourceForge.net)
Date: Fri, 31 Jan 2003 15:22:24 -0800
Subject: [Patches] [ python-Patches-678218 ] Adds icon support to bundlebuilder.py
Message-ID: <E18ekUK-000747-00@sc8-sf-web2.sourceforge.net>

Patches item #678218, was opened at 2003-01-31 17:44
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678218&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Dunn (robind)
>Assigned to: Just van Rossum (jvr)
Summary: Adds icon support to bundlebuilder.py

Initial Comment:
This patch adds support for an --iconfile parameter and
etc. to bundlebuilder.py and if given will copy the
given icon file to the bundle's resources and will set
the CFBundleIconFile value in the plist file.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2003-02-01 00:22

Message:
Logged In: YES 
user_id=45365

Another of Just's scriipts that I'm not familiar with (yet)...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=678218&group_id=5470