From noreply@sourceforge.net  Wed May  1 04:33:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 30 Apr 2002 20:33:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-550409 ] What does os.read() return on EOF?
Message-ID: <E172kro-0001Pd-00@usw-sf-web4.sourceforge.net>

Bugs item #550409, was opened at 2002-04-29 18:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550409&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: What does os.read() return on EOF?

Initial Comment:
You may want to note that os.read() returns 
(apparently) an empty string on EOF. This appears to 
be true of regular files and of file descriptor 
returned by pty.fork().

Yours,
Noah

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-30 23:33

Message:
Logged In: YES 
user_id=3066

Added the information in Doc/lib/libos.tex revisions 1.84,
1.74.2.1.2.3, and 1.53.4.7.

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

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



From noreply@sourceforge.net  Wed May  1 19:37:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 May 2002 11:37:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-549338 ] lib-dynload/*.so permissions wrong
Message-ID: <E172yz5-0004Tb-00@usw-sf-web1.sourceforge.net>

Bugs item #549338, was opened at 2002-04-27 01:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549338&group_id=5470

Category: Installation
Group: Python 2.2
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: J. Lewis Muir (jlmuir)
>Assigned to: Michael Hudson (mwh)
Summary: lib-dynload/*.so permissions wrong

Initial Comment:
After

    ./configure --prefix=<PYTHON_INSTALL_DIR>
    make
    make test
    make install

the .so files installed 
in '<PYTHON_INSTALL_DIR>/lib/python2.2/lib-dynload' 
have permissions set to 700. They should instead have 
file permissions set to 755.

Running the python interpreter as a non-root user with 
the lib-dynload/*.so file permissions set to 700 (as 
is done by the install), a simple import of the time 
module fails:

    >>> import time
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ImportError: No module named time
    >>>

After changing file permissions to 755, 'import time' 
works fine.

---
Python 2.2.1
Mandrake 8.0
Linux 2.4.8
x86 hardware

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

>Comment By: Michael Hudson (mwh)
Date: 2002-05-01 18:37

Message:
Logged In: YES 
user_id=6656

This is a dup of #425007 (which is languishing on my plate).

Feel free to help fix it...

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

Comment By: J. Lewis Muir (jlmuir)
Date: 2002-04-29 23:02

Message:
Logged In: YES 
user_id=527708

The umask was set to 022.

To be exact, the 'configure', 'make', and 'make test' were 
run as a normal user with umask set to 077. I then 'su'ed 
as root (using the command 'su - root', making the shell a 
login shell) where my umask became 022 and then ran 'make 
install'.

Both the normal user shell and the root shell were GNU 
bash, version 2.05.1(1)-release.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-28 14:00

Message:
Logged In: YES 
user_id=21627

When you perform the installation, what is your umask?

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

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



From noreply@sourceforge.net  Wed May  1 19:40:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 May 2002 11:40:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-549907 ] Wrong #ifdef in _localemodule.c
Message-ID: <E172z1N-0002Ku-00@usw-sf-web3.sourceforge.net>

Bugs item #549907, was opened at 2002-04-28 21:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549907&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raj Srinivasan (rsrini)
>Assigned to: Martin v. Löwis (loewis)
Summary: Wrong #ifdef in _localemodule.c

Initial Comment:
At line 642 should be #ifdef HAVE_LIBINTL_H instead of
#ifdef HAVE_LANGINFO_H

raj



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

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



From noreply@sourceforge.net  Thu May  2 04:32:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 May 2002 20:32:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-227361 ] httplib problem with '100 Continue'
Message-ID: <E1737KH-0007LU-00@usw-sf-web2.sourceforge.net>

Bugs item #227361, was opened at 2001-01-02 18:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227361&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Fort (dougfort)
Assigned to: Greg Stein (gstein)
Summary: httplib problem with '100 Continue'

Initial Comment:
I believe there is a bug in httplib 

IIS 4 and 5 are subject to send an unsolicited result code of '100 Continue' with a couple of headers and a blank line before sending '302 Object Moved'.

The 100 response is totally worthless and should be ignored.  Unfortunately, httplib.HTTPConnection is unwilling to go back and read more headers when it
already has a response object.

I was able to get past this with the following kludge:

    while 1:
        response = self._client.getresponse()
        if response.status != 100:
            break
        # 2000-12-30 djf -- drop bogus 100 response
        # by kludging httplib
        self._client._HTTPConnection__state = httplib._CS_REQ_SENT
        self._client._HTTPConnection__response = None



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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-01 20:32

Message:
Logged In: NO 

I've got a patch for this bug.  How do I submit it?

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

Comment By: Jens B. Jorgensen (jensbjorgensen)
Date: 2002-03-01 16:15

Message:
Logged In: YES 
user_id=67930

I did submit a patch for this, not sure if you noticed. I've
been using it for quite a while and it seems to be working
flawlessly, granted I'm always pretty much using it in the
same context.

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

Comment By: Greg Stein (gstein)
Date: 2002-03-01 15:12

Message:
Logged In: YES 
user_id=6501

Yup, I'll clear out all the httplib bugs... not a problem. I
didn't get free time until the end of the 2.2 cycle, so I
punted until now.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 14:48

Message:
Logged In: YES 
user_id=31392

Greg,

Will you be able to work on this for 2.3?


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

Comment By: Jens B. Jorgensen (jensbjorgensen)
Date: 2002-02-11 07:58

Message:
Logged In: YES 
user_id=67930

Whether or not the library transparently consumes 100
responses (which I believe it should) or not there is no
question the current behavior represents a bug. When a 100
response is received the connection get's "stuck" because it
believes it has already read a response and refuses to read
another until another request is sent. Once you hit this
with the HTTPConnection you cannot do anything with it
unless you modify its internal state data.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-11 01:54

Message:
Logged In: NO 

This may not be a problem at all, depending on how the 
authors of httplib intended to process this header. I 
haven't read their spec so I don't know what they intended.

Here is the section on response code 100 from RFC 2616 
(HTTP 1.1) so you can make up your own mind:

10.1.1 100 Continue

#######################################################
The client SHOULD continue with its request. This interim 
response is used to inform the client that the initial part 
of the request has been received and has not yet been 
rejected by the server. The client SHOULD continue by 
sending the remainder of the request or, if the request has 
already been completed, ignore this response. The server 
MUST send a final response after the request has been 
completed. See section 8.2.3 for detailed discussion of the 
use and handling of this status code.
#######################################################

If you take a look at section 8.2.3, you will find some 
very good reasons why this header responds as it does. You 
might also be able to solve your problem just by reading 
these to section of the spec.

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

Comment By: Doug Fort (dougfort)
Date: 2001-01-06 12:14

Message:
I'm not sure httplib should know anything about the actual status.  Right now it is elegantly decoupled from the content it handles. Perhaps just a 'discardresponse()' function.

BTW, I've had very good results with the HTTP 1.1 functionality in general.  This is a small nit.

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

Comment By: Greg Stein (gstein)
Date: 2001-01-06 12:04

Message:
Agreed -- this is a problem in httplib. I was hoping to get the "chewing up" of 100 (Continue) responses into httplib before the 2.0 release.

It should be possible to do this in HTTPResponse.begin()

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

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



From noreply@sourceforge.net  Thu May  2 07:08:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 May 2002 23:08:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-551285 ] xrange object attributes broken
Message-ID: <E1739l9-0001AJ-00@usw-sf-web4.sourceforge.net>

Bugs item #551285, was opened at 2002-05-02 02:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551285&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xrange object attributes broken

Initial Comment:
The start, stop, step, and tolist attributes of xrange
objects can no longer be retrieved.  This appears to
have broken when the attribute lookup machinery changed
with the type/class unification.

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

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



From noreply@sourceforge.net  Thu May  2 12:11:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 May 2002 04:11:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-551353 ] Python build not Solaris friendly
Message-ID: <E173EUL-0006hE-00@usw-sf-web1.sourceforge.net>

Bugs item #551353, was opened at 2002-05-02 06:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551353&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Phil Eschallier (eschaa00)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python build not Solaris friendly

Initial Comment:
In summary: distutils picks up and uses the proper
values for -I and -L when compiling.  However, Solaris
(and likely other SysV UNIX variants) need -R to the
linker as well.

I posted something to USENET trying to help someone
having _socket problems under Solaris.  The follow-ups
suggested that I create this bug report.

>From USENET:

Folks;

I'm in no way a Python expert ... but I've been playing
with it under
Solaris for the last week, thinking that we should make
the jump from
perl (a different thread).

I wanted to follow-up noting that the build process for
Python under
Solaris is less than perfect.  I've experienced this
same _socket
module not being found and "yes", the build is broken.

The root of the issue is that the distutils used for
compiling
determine the libs needed and add the -I / -L as
needed.  But no -R
options are added.  My problem came from the fact that
I have OpenSSL
deployed under /usr/local/ssl ... and the build process
adds the -L to
find ssl.so and crypt.so ... but the resulting
_socket.so does not
have the runtime path to the OpenSSL libs, the test
load of _socket.so
fails, and it is removed from the build.  The same
holds for TK
support and one or two others.

Under Linux this is a non-issues as ldconfig is available.

My work-around for now is to add all the -L / -R
directives I need to
the CC environment variable before running the initial
'configure'
script (because only hte CC and LDSHARED variables are
passed from
Makefile to setyp.py).

I hope this helps ... and I hope that Python becomes
more Solaris
friendly as it matures.


Cheers.

-- 
Phil Eschallier
Bux Technical Services
70 Irish Meetinghouse Rd
Perkasie, PA  18944
215.249.TECH (215.249.8324)
215.249.8325 (fax)
http://www.BuxTech.Com


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

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



From noreply@sourceforge.net  Thu May  2 13:17:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 May 2002 05:17:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-549907 ] Wrong #ifdef in _localemodule.c
Message-ID: <E173FWD-0004fg-00@usw-sf-web2.sourceforge.net>

Bugs item #549907, was opened at 2002-04-28 23:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549907&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Raj Srinivasan (rsrini)
Assigned to: Martin v. Löwis (loewis)
Summary: Wrong #ifdef in _localemodule.c

Initial Comment:
At line 642 should be #ifdef HAVE_LIBINTL_H instead of
#ifdef HAVE_LANGINFO_H

raj



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-02 14:17

Message:
Logged In: YES 
user_id=21627

Thanks for the report. Fixed in _localemodule.c 2.31.

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

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



From noreply@sourceforge.net  Thu May  2 13:27:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 May 2002 05:27:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-551353 ] Python build not Solaris friendly
Message-ID: <E173Ffz-0005JQ-00@usw-sf-web4.sourceforge.net>

Bugs item #551353, was opened at 2002-05-02 13:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551353&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Phil Eschallier (eschaa00)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python build not Solaris friendly

Initial Comment:
In summary: distutils picks up and uses the proper
values for -I and -L when compiling.  However, Solaris
(and likely other SysV UNIX variants) need -R to the
linker as well.

I posted something to USENET trying to help someone
having _socket problems under Solaris.  The follow-ups
suggested that I create this bug report.

>From USENET:

Folks;

I'm in no way a Python expert ... but I've been playing
with it under
Solaris for the last week, thinking that we should make
the jump from
perl (a different thread).

I wanted to follow-up noting that the build process for
Python under
Solaris is less than perfect.  I've experienced this
same _socket
module not being found and "yes", the build is broken.

The root of the issue is that the distutils used for
compiling
determine the libs needed and add the -I / -L as
needed.  But no -R
options are added.  My problem came from the fact that
I have OpenSSL
deployed under /usr/local/ssl ... and the build process
adds the -L to
find ssl.so and crypt.so ... but the resulting
_socket.so does not
have the runtime path to the OpenSSL libs, the test
load of _socket.so
fails, and it is removed from the build.  The same
holds for TK
support and one or two others.

Under Linux this is a non-issues as ldconfig is available.

My work-around for now is to add all the -L / -R
directives I need to
the CC environment variable before running the initial
'configure'
script (because only hte CC and LDSHARED variables are
passed from
Makefile to setyp.py).

I hope this helps ... and I hope that Python becomes
more Solaris
friendly as it matures.


Cheers.

-- 
Phil Eschallier
Bux Technical Services
70 Irish Meetinghouse Rd
Perkasie, PA  18944
215.249.TECH (215.249.8324)
215.249.8325 (fax)
http://www.BuxTech.Com


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-02 14:27

Message:
Logged In: YES 
user_id=21627

When you say that you can accept the Linux build because of
ldconfig(8), then I suggest using crle(1) on Solaris - it
does exactly the same thing.

You have the following options on Solaris:
1) build static PIC libraries of SSL, and use those
2) use crle
3) set LD_RUN_PATH before configuring Python
4) edit Modules/Setup
5) set LD_LIBRARY_PATH at run time

I think these are plenty of options. The Python build is not
Solaris-unfriendly - just if you, as an administrator,
install additional shared libraries on your system, you must
take additional steps when you want to use them.

Outright adding a -R option for every -L option is not the
right solution; if the library to link is static-with-PIC,
then this would be wrong; if crle is used, this would be
also wrong. My recommendation is to abstain from shared
libraries in non-standard directories.

In short, I don't think there is much that can be done about
this. In Python 2.3, the socket and ssl modules are
separate, so you will get socket module even if building the
ssl module fails.

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

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



From noreply@sourceforge.net  Thu May  2 14:42:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 May 2002 06:42:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-551412 ] possible to fail to calc mro's
Message-ID: <E173Gqo-0005gl-00@usw-sf-web2.sourceforge.net>

Bugs item #551412, was opened at 2002-05-02 13:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: possible to fail to calc mro's

Initial Comment:
This only crashes on the release22-maint branch, and
only when coredump is true:

class UserLong(object):
    def __pow__(self, *args):
        pass

coredump = 1

if not coredump:
   int.__mro__

pow(0, UserLong(), 0)

It's the type of the first argument to pow() that's
relavent: if you change it to "pow(0L, UserLong(), 0)"
you then have to change "int.__mro__" to "long.__mro__"
to avoid the crash.

Maybe it was the "typeobject.c refactoring" patch that
accidentally fixed this on the trunk?

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

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



From noreply@sourceforge.net  Thu May  2 17:22:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 May 2002 09:22:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-227361 ] httplib problem with '100 Continue'
Message-ID: <E173JLq-0001kf-00@usw-sf-web1.sourceforge.net>

Bugs item #227361, was opened at 2001-01-02 20:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227361&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Fort (dougfort)
Assigned to: Greg Stein (gstein)
Summary: httplib problem with '100 Continue'

Initial Comment:
I believe there is a bug in httplib 

IIS 4 and 5 are subject to send an unsolicited result code of '100 Continue' with a couple of headers and a blank line before sending '302 Object Moved'.

The 100 response is totally worthless and should be ignored.  Unfortunately, httplib.HTTPConnection is unwilling to go back and read more headers when it
already has a response object.

I was able to get past this with the following kludge:

    while 1:
        response = self._client.getresponse()
        if response.status != 100:
            break
        # 2000-12-30 djf -- drop bogus 100 response
        # by kludging httplib
        self._client._HTTPConnection__state = httplib._CS_REQ_SENT
        self._client._HTTPConnection__response = None



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

Comment By: Jens B. Jorgensen (jensbjorgensen)
Date: 2002-05-02 11:22

Message:
Logged In: YES 
user_id=67930

I've already submitted a patch for this:

http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227361&group_id=5470

Just waiting for it to be accepted.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-01 22:32

Message:
Logged In: NO 

I've got a patch for this bug.  How do I submit it?

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

Comment By: Jens B. Jorgensen (jensbjorgensen)
Date: 2002-03-01 18:15

Message:
Logged In: YES 
user_id=67930

I did submit a patch for this, not sure if you noticed. I've
been using it for quite a while and it seems to be working
flawlessly, granted I'm always pretty much using it in the
same context.

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

Comment By: Greg Stein (gstein)
Date: 2002-03-01 17:12

Message:
Logged In: YES 
user_id=6501

Yup, I'll clear out all the httplib bugs... not a problem. I
didn't get free time until the end of the 2.2 cycle, so I
punted until now.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 16:48

Message:
Logged In: YES 
user_id=31392

Greg,

Will you be able to work on this for 2.3?


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

Comment By: Jens B. Jorgensen (jensbjorgensen)
Date: 2002-02-11 09:58

Message:
Logged In: YES 
user_id=67930

Whether or not the library transparently consumes 100
responses (which I believe it should) or not there is no
question the current behavior represents a bug. When a 100
response is received the connection get's "stuck" because it
believes it has already read a response and refuses to read
another until another request is sent. Once you hit this
with the HTTPConnection you cannot do anything with it
unless you modify its internal state data.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-11 03:54

Message:
Logged In: NO 

This may not be a problem at all, depending on how the 
authors of httplib intended to process this header. I 
haven't read their spec so I don't know what they intended.

Here is the section on response code 100 from RFC 2616 
(HTTP 1.1) so you can make up your own mind:

10.1.1 100 Continue

#######################################################
The client SHOULD continue with its request. This interim 
response is used to inform the client that the initial part 
of the request has been received and has not yet been 
rejected by the server. The client SHOULD continue by 
sending the remainder of the request or, if the request has 
already been completed, ignore this response. The server 
MUST send a final response after the request has been 
completed. See section 8.2.3 for detailed discussion of the 
use and handling of this status code.
#######################################################

If you take a look at section 8.2.3, you will find some 
very good reasons why this header responds as it does. You 
might also be able to solve your problem just by reading 
these to section of the spec.

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

Comment By: Doug Fort (dougfort)
Date: 2001-01-06 14:14

Message:
I'm not sure httplib should know anything about the actual status.  Right now it is elegantly decoupled from the content it handles. Perhaps just a 'discardresponse()' function.

BTW, I've had very good results with the HTTP 1.1 functionality in general.  This is a small nit.

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

Comment By: Greg Stein (gstein)
Date: 2001-01-06 14:04

Message:
Agreed -- this is a problem in httplib. I was hoping to get the "chewing up" of 100 (Continue) responses into httplib before the 2.0 release.

It should be possible to do this in HTTPResponse.begin()

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

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



From noreply@sourceforge.net  Thu May  2 17:29:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 May 2002 09:29:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-551285 ] xrange object attributes broken
Message-ID: <E173JSN-0001pS-00@usw-sf-web1.sourceforge.net>

Bugs item #551285, was opened at 2002-05-02 02:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551285&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xrange object attributes broken

Initial Comment:
The start, stop, step, and tolist attributes of xrange
objects can no longer be retrieved.  This appears to
have broken when the attribute lookup machinery changed
with the type/class unification.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-02 12:29

Message:
Logged In: YES 
user_id=3066

Fixed in Objects/rangeobject.c revisions 2.34 and 2.30.6.2.
 Added regression tests in Lib/test/test_b2.py revisions
1.32, 1.29.6.2, and 1.24.4.1.

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

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



From noreply@sourceforge.net  Thu May  2 18:17:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 May 2002 10:17:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-551504 ] python -v sometimes fails to find init
Message-ID: <E173KCy-00009L-00@usw-sf-web3.sourceforge.net>

Bugs item #551504, was opened at 2002-05-02 12:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551504&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Joseph Winston (josephwinston)
Assigned to: Nobody/Anonymous (nobody)
Summary: python -v sometimes fails to find init

Initial Comment:
On HP-UX 11 python -v sometimes fails to find the init 
method for a
dynamic library.  An instance of this can be found 
when trying to load
libsip.  A possible work around is the following patch:

diff -c -c -r1.1 dynload_hpux.c
*** dynload_hpux.c	2 May 2002 16:04:08 -0000
	1.1
--- dynload_hpux.c	2 May 2002 17:12:01 -0000
***************
*** 29,35 ****
  
  	flags = BIND_FIRST | BIND_DEFERRED;
  	if (Py_VerboseFlag) {
! 		flags = DYNAMIC_PATH | BIND_FIRST | 
BIND_IMMEDIATE |
  			BIND_NONFATAL | BIND_VERBOSE;
  		printf("shl_load %s\n",pathname);
  	}
--- 29,35 ----
  
  	flags = BIND_FIRST | BIND_DEFERRED;
  	if (Py_VerboseFlag) {
! 		flags = BIND_FIRST | BIND_IMMEDIATE |
  			BIND_NONFATAL | BIND_VERBOSE;
  		printf("shl_load %s\n",pathname);
  	}

I do not know why DYNAMIC_PATH is causing the loading 
to fail since
the man page for shl_load says:

DYNAMIC_PATH Allow the loader todynamically search for 
the library
specified by the path argument.  The directories to be 
searched are
determined by the +s and +b options of the ld command 
used when the
program was linked.  On PA64, this is enabled by 
default if ld +compat
was not specified.


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

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



From noreply@sourceforge.net  Thu May  2 20:20:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 May 2002 12:20:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-551551 ] type->tp_mro NULL, typeobject.c:1217
Message-ID: <E173M7Y-00010c-00@usw-sf-web2.sourceforge.net>

Bugs item #551551, was opened at 2002-05-02 19:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551551&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Luke Kenneth Casson Leighton (lkcl)
Assigned to: Nobody/Anonymous (nobody)
Summary: type->tp_mro NULL, typeobject.c:1217

Initial Comment:
a segfault occurs at line 1217 in typeobject.c due to
type->tp_mro being NULL.

the following small testcode example repros the case:

class UserLong(object):

    def __pow__(self, *args):
        print "don't have to do anything, just declare
the function"
        print "putting def __pow__(self, x, y): doesn't
affect segfault"

print pow(5, UserLong(3L), 26)


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

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



From noreply@sourceforge.net  Fri May  3 01:49:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 May 2002 17:49:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-551673 ] Poor error message for float()
Message-ID: <E173RG0-0004cT-00@usw-sf-web2.sourceforge.net>

Bugs item #551673, was opened at 2002-05-03 00:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551673&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward C. Jones (edcjones)
Assigned to: Nobody/Anonymous (nobody)
Summary: Poor error message for float()

Initial Comment:
This line of Python (2.2):

    x = float([0])

gives the error:

    TypeError: float() needs a string argument

But since "float(0)" is OK, a better error message
might be:

    TypeError: the argument of float() must be a string
or a number

I use RedHat 7.1 Linux on a PC.


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

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



From noreply@sourceforge.net  Fri May  3 13:59:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 May 2002 05:59:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-551828 ] PDF won't print
Message-ID: <E173cfH-0004kK-00@usw-sf-web4.sourceforge.net>

Bugs item #551828, was opened at 2002-05-03 08:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551828&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Shaun Devlin (ssdevlin)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PDF won't print

Initial Comment:
On Windows 98SE with Acrobat reader 5.0.5
several pdf documents (inst.pdf, whatnew.pdf, ref.pdf,
etc) will not print although they display fine.
This has been observed on two computers and two printers
(Laser Jet IIIP, Brother HL-1650) neither with hardware
postscript emulation.
Sometimes the first page prints.
These systems can print other pdf documents

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

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



From noreply@sourceforge.net  Fri May  3 17:22:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 May 2002 09:22:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-551912 ] mimify.mime_decode_header only latin1
Message-ID: <E173fos-0006aV-00@usw-sf-web3.sourceforge.net>

Bugs item #551912, was opened at 2002-05-03 18:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551912&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Nobody/Anonymous (nobody)
Summary: mimify.mime_decode_header only latin1

Initial Comment:
This function only works for iso-8859-1. If you look at
the regex it uses, it's also clear why. I'll try to
come up with a patch.

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

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



From noreply@sourceforge.net  Fri May  3 17:48:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 May 2002 09:48:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-551912 ] mimify.mime_decode_header only latin1
Message-ID: <E173gEg-0007Q2-00@usw-sf-web2.sourceforge.net>

Bugs item #551912, was opened at 2002-05-03 18:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551912&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Nobody/Anonymous (nobody)
Summary: mimify.mime_decode_header only latin1

Initial Comment:
This function only works for iso-8859-1. If you look at
the regex it uses, it's also clear why. I'll try to
come up with a patch.

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

>Comment By: Gerhard Häring (ghaering)
Date: 2002-05-03 18:48

Message:
Logged In: YES 
user_id=163326

Some of the code in this module is rather brain-dead (not
unicode-aware, hard-wired to latin1). Maybe it's best to
deprecate it or mark it as buggy in the docs. The new email
module provides better functions for this, anyway (info from
MvL):

email.Utils.decode (Python 2.2)

email.Header.decode_header (CVS)

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

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



From noreply@sourceforge.net  Fri May  3 17:49:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 May 2002 09:49:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-551912 ] mimify.mime_decode_header only latin1
Message-ID: <E173gF4-0000P8-00@usw-sf-web1.sourceforge.net>

Bugs item #551912, was opened at 2002-05-03 18:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551912&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Häring (ghaering)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: mimify.mime_decode_header only latin1

Initial Comment:
This function only works for iso-8859-1. If you look at
the regex it uses, it's also clear why. I'll try to
come up with a patch.

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-05-03 18:48

Message:
Logged In: YES 
user_id=163326

Some of the code in this module is rather brain-dead (not
unicode-aware, hard-wired to latin1). Maybe it's best to
deprecate it or mark it as buggy in the docs. The new email
module provides better functions for this, anyway (info from
MvL):

email.Utils.decode (Python 2.2)

email.Header.decode_header (CVS)

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

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



From noreply@sourceforge.net  Fri May  3 18:05:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 May 2002 10:05:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-551912 ] mimify.mime_decode_header only latin1
Message-ID: <E173gVC-00073x-00@usw-sf-web3.sourceforge.net>

Bugs item #551912, was opened at 2002-05-03 12:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551912&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Häring (ghaering)
Assigned to: Barry Warsaw (bwarsaw)
Summary: mimify.mime_decode_header only latin1

Initial Comment:
This function only works for iso-8859-1. If you look at
the regex it uses, it's also clear why. I'll try to
come up with a patch.

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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-03 13:05

Message:
Logged In: YES 
user_id=12800

Yup, I agree.  For a while, I've wanted to deprecate mimify,
(the api to) rfc822, MIMEWriter, and mimetools.  I think the
hangup on doing this for Python 2.2 was to try to come up
with recipes for folks to migrate their code to the email
package.  I don't have time to do that though.  Maybe a faq
or howto on the email package could address these issues, so
that we can deprecate them for Python2.3 (but not remove
them for a long time, probably 2 years at least, see PEP 4)

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-05-03 12:48

Message:
Logged In: YES 
user_id=163326

Some of the code in this module is rather brain-dead (not
unicode-aware, hard-wired to latin1). Maybe it's best to
deprecate it or mark it as buggy in the docs. The new email
module provides better functions for this, anyway (info from
MvL):

email.Utils.decode (Python 2.2)

email.Header.decode_header (CVS)

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

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



From noreply@sourceforge.net  Fri May  3 23:27:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 May 2002 15:27:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-508944 ] socket-module SSL is broken
Message-ID: <E173lWr-0003ys-00@usw-sf-web1.sourceforge.net>

Bugs item #508944, was opened at 2002-01-26 20:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508944&group_id=5470

Category: Extension Modules
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Ribbens (jribbens)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket-module SSL is broken

Initial Comment:
If you set a socket to non-blocking and then try to 
call socket.ssl on it, it fails because you are doing 
all the setup and calling SSL_connect as an 
indivisible operation in the object constructor. So 
you can't catch SSL_ERROR_WANT_READ/WRITE and restart 
SSL_connect because there is no way from python to 
call SSL_connect. (Don't tell me not to set the socket 
non-blocking - I need to implement timeouts. And don't 
tell me to use alarm(), my program is multi-threaded.)

For the same reason, there is no way in Python to 
write an SSL server. The only way to create an SSL 
object is socket.ssl and it is hardcoded to call 
SSL_connect, you can't call SSL_accept.

Please can you make it so that a new function in the 
socket module creates a proper SSL object (that 
preferably has actual useful methods to set the 
options, etc) that is not connected in its constructor 
so that you can then call SSL_connect or SSL_accept. 
It could then also have a makefile method like socket 
objects which would implement read and write properly 
(i.e. catching and handling 
WANT_READ/WANT_WRITE/ZERO_RETURN). You could even then 
make it so that it has methods to set the various 
options that OpenSSL provides rather than hard-coding 
them in the SSLObject constructor.

Umm, sorry if I sound tetchy but due to the complete 
lack of documentation of the socket SSL facilities 
I've just spent ages trying to work out why my program 
wasn't working, only to discover that it's not 
possible to get it working.

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-05-04 00:27

Message:
Logged In: YES 
user_id=163326

If you need to write SSL servers *now*, you can use one of
the various third-party SSL libraries for Python: m2crypto,
pyOpenSSL, POW.

Fixing Python's SSL will most probably require a full
rewrite, and there's no consensus yet about if and how to do
this.

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

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



From noreply@sourceforge.net  Sat May  4 16:12:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 May 2002 08:12:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-552262 ] 'testlist" undefined in grammar
Message-ID: <E1741Ck-0004Hr-00@usw-sf-web2.sourceforge.net>

Bugs item #552262, was opened at 2002-05-04 15:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=552262&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Everhart (deverhart)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 'testlist" undefined in grammar

Initial Comment:
In http://www.python.org/doc/current/ref/grammar.txt 
the production

list_for ::= 
             "for" expression_list "in" testlist
              [list_iter]

refers to the nonterminal 'testlist', which does not 
appear anywhere else in the document.
  

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

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



From noreply@sourceforge.net  Sat May  4 21:53:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 May 2002 13:53:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-552345 ] rfc822.parsedate() too strict
Message-ID: <E1746X6-0007Ph-00@usw-sf-web3.sourceforge.net>

Bugs item #552345, was opened at 2002-05-04 16:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=552345&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Barry Warsaw (bwarsaw)
Summary: rfc822.parsedate() too strict

Initial Comment:
rfc822.parsedate('Wed,3 Apr 2002 14:58:26 +0800')
returns None.  Note the lack of space between the
command and the 3.  That space is actually optional in
RFC 2822, so it should parse the same as 
parsedate('Wed, 3 Apr 2002 14:58:26 +0800')


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

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



From noreply@sourceforge.net  Sun May  5 16:55:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 05 May 2002 08:55:27 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-426539 ] Math-module lacks some docs and funcs
Message-ID: <E174OMB-0005ZQ-00@usw-sf-web1.sourceforge.net>

Feature Requests item #426539, was opened at 2001-05-23 04:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=426539&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Later
Priority: 5
Submitted By: Rikard Bosnjakovic (bosna)
Assigned to: Nobody/Anonymous (nobody)
Summary: Math-module lacks some docs and funcs

Initial Comment:
>>> import math
>>> print math.cos.__doc__
cos(x)

Return the cosine of x.


1. That doc-string is not very sufficient, since it
does not tell whether x should be in radians or
degrees. Same goes with sin, asin, acos and the rest of
the degree-functions.

2. ceil() and floor() could have some more information
of what the functions does. Not all users have taken
math-courses and know about them.

3. Add a degrees(x) and radians(x) that converts "x" to
degrees (from a radian argument) and to radians (from a
degree argument) respectively, it's pretty useful.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-05 15:55

Message:
Logged In: YES 
user_id=80475

As of version 2.2, comments #1 and #2 were resolved.
Submitted patch for #3:  www.python.org/sf/552452


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

Comment By: Tim Peters (tim_one)
Date: 2001-06-04 18:38

Message:
Logged In: YES 
user_id=31435

Chagned to Feature Request, Interpreter Core, and added two 
entries to PEP 42 (one for fatter docs, another for the new 
functions).

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

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



From noreply@sourceforge.net  Sun May  5 16:57:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 05 May 2002 08:57:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-548874 ] Lists do have __getitem__ method
Message-ID: <E174OO6-00049U-00@usw-sf-web4.sourceforge.net>

Bugs item #548874, was opened at 2002-04-26 00:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548874&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kelly Gerber (kgerber)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lists do have __getitem__ method

Initial Comment:
In the Python Reference Manual, Release 2.2.1, section
3.3 Special method names, first paragraph, it says"(The
reverse is not true--if x is a list object,
x.__getitem__(i) is not equivalent to x[i].)"

I do not think this is true any more since Python2.2,
because types now have special methods. They both seem
to produce the same result. Doesn't that make them
equivalent?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-05 15:57

Message:
Logged In: YES 
user_id=80475

Agreed.
Submitted documentation patch: www.python.org/sf/552468

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

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



From noreply@sourceforge.net  Sun May  5 21:51:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 05 May 2002 13:51:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-551828 ] PDF won't print
Message-ID: <E174SyV-0007Lo-00@usw-sf-web4.sourceforge.net>

Bugs item #551828, was opened at 2002-05-03 14:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551828&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Shaun Devlin (ssdevlin)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PDF won't print

Initial Comment:
On Windows 98SE with Acrobat reader 5.0.5
several pdf documents (inst.pdf, whatnew.pdf, ref.pdf,
etc) will not print although they display fine.
This has been observed on two computers and two printers
(Laser Jet IIIP, Brother HL-1650) neither with hardware
postscript emulation.
Sometimes the first page prints.
These systems can print other pdf documents

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-05-05 22:51

Message:
Logged In: YES 
user_id=45365

The same is true on Mac OS X, Acrobat Reader 5.0. Observed on a LaserJet 4500. It is also true for other documents formatted with the Python TeX macro stuff, such as the recent unicode document. Some documents print a few pages, some print nothing at all.

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

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



From noreply@sourceforge.net  Mon May  6 08:55:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 May 2002 00:55:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-408271 ] crash in shelve module
Message-ID: <E174dLM-0005Ry-00@usw-sf-web3.sourceforge.net>

Bugs item #408271, was opened at 2001-03-14 05:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470

Category: Python Library
Group: Irreproducible
Status: Closed
Resolution: None
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: crash in shelve module

Initial Comment:
While using shelve module on SGI
sloth 271> uname -a
IRIX64 sloth 6.5 04191225 IP27

my python program crashes and
I am getting following error message:

  File "/usr/local/lib/python1.5/shelve.py", line 71,
in __setitem__
    self.dict[key] = f.getvalue()
bsddb.error: (0, 'Error')

At the time the size of the "shelve" file was quite big
(maybe this is a problem ?)
sloth 267> ls -lt *shelve
-rw-r--r--    1 ryszard  cdiApps   85778432 Mar 13
12:27 recap_mddr.shelve


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

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 17:55

Message:
Logged In: YES 
user_id=59803

You might want to re-open this one, Barry. The problem 
seems to be with any large number of bsddb inserts, which 
can also be triggered by shelve. See: 

http://www.deadlybloodyserious.com/Python/2002/05/06.html

http://bugs.activestate.com/show_bug.cgi?id=10242 

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-03-19 03:10

Message:
Logged In: YES 
user_id=12800

Besides, this was submitted by "anonymous" and the only clue
to the identity of the original poster is in the ls output. 
Unfortunately, I'm not prepared to spam all the Ryszard's in
my name database. :)

I'm closing this report until/unless we get more
information.

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

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

Message:
Logged In: YES 
user_id=31435

Assigned to Barry because there's not enough info here to 
do anything about it <wink>.

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

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



From noreply@sourceforge.net  Mon May  6 16:13:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 May 2002 08:13:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-408271 ] crash in shelve module
Message-ID: <E174kBT-00037Y-00@usw-sf-web1.sourceforge.net>

Bugs item #408271, was opened at 2001-03-13 13:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470

Category: Python Library
>Group: None
Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: crash in shelve module

Initial Comment:
While using shelve module on SGI
sloth 271> uname -a
IRIX64 sloth 6.5 04191225 IP27

my python program crashes and
I am getting following error message:

  File "/usr/local/lib/python1.5/shelve.py", line 71,
in __setitem__
    self.dict[key] = f.getvalue()
bsddb.error: (0, 'Error')

At the time the size of the "shelve" file was quite big
(maybe this is a problem ?)
sloth 267> ls -lt *shelve
-rw-r--r--    1 ryszard  cdiApps   85778432 Mar 13
12:27 recap_mddr.shelve


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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-06 11:13

Message:
Logged In: YES 
user_id=12800

I'd highly suggest that any serious work with BerkeleyDB be
done with pybsddb and a more modern version of Berkeley. 
The bsddb module that comes with Python 2.2 has serious
problems, including not being able to link on some *nix
distros.  Also BDB 1.85 is way way old and has many known
problems. 

I ran the deadlybloddyserious example using BDB 3.11 and
pybsddb 3.0 and it passed with flying colors.  See
www.sleepycat.com for the latest BDB's and pybsddb.sf.net
for the latest Python wrappers.

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

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 03:55

Message:
Logged In: YES 
user_id=59803

You might want to re-open this one, Barry. The problem 
seems to be with any large number of bsddb inserts, which 
can also be triggered by shelve. See: 

http://www.deadlybloodyserious.com/Python/2002/05/06.html

http://bugs.activestate.com/show_bug.cgi?id=10242 

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-03-18 11:10

Message:
Logged In: YES 
user_id=12800

Besides, this was submitted by "anonymous" and the only clue
to the identity of the original poster is in the ls output. 
Unfortunately, I'm not prepared to spam all the Ryszard's in
my name database. :)

I'm closing this report until/unless we get more
information.

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

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

Message:
Logged In: YES 
user_id=31435

Assigned to Barry because there's not enough info here to 
do anything about it <wink>.

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

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



From noreply@sourceforge.net  Mon May  6 18:05:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 May 2002 10:05:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-421384 ] bad floating point precision
Message-ID: <E174lvF-0003rr-00@usw-sf-web2.sourceforge.net>

Bugs item #421384, was opened at 2001-05-04 10:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421384&group_id=5470

Category: None
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bad floating point precision

Initial Comment:
Platform: P3-700, Win2k (SP0), Python 2.1, IDLE 0.8.
Floating point calculations seem to have a very bad 
precision. Below is a log of a session. Things are 
getting worse when comparing two floating point 
values - in this example, 2.1*2/2 != 2.1!

#--[LOG START]--
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
IDLE 0.8 -- press F1 for help
>>> 2.1*2
4.2000000000000002
>>> 2.1*2/2
2.1000000000000001
>>> 
#--[LOG END]--


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

Comment By: Michael Donegan (invader8)
Date: 2002-05-06 12:05

Message:
Logged In: YES 
user_id=537045

This bug still exists in Python 2.2 (#1, Dec 31 2001, 15:21:18)
Should it be closed?

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-04 14:04

Message:
Logged In: YES 
user_id=31435

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for a detailed example:

http://www.python.org/cgi-bin/moinmoin/RepresentationError


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

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



From noreply@sourceforge.net  Mon May  6 18:10:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 May 2002 10:10:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-226586 ] Floating point is broken in Python 2.0
Message-ID: <E174m00-0004Wa-00@usw-sf-web1.sourceforge.net>

Bugs item #226586, was opened at 2000-12-21 06:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=226586&group_id=5470

Category: IDLE
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Floating point is broken in Python 2.0

Initial Comment:
Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> p=0.6
>>> p
0.59999999999999998
>>> 

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

Comment By: Michael Donegan (invader8)
Date: 2002-05-06 12:10

Message:
Logged In: YES 
user_id=537045

This is still a problem in
Python 2.2 (#1, Dec 31 2001, 15:21:18)

It is a bug. Why would we expect that
the interactive prompt would behave
differently (worse) from using print?

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

Comment By: Tim Peters (tim_one)
Date: 2000-12-21 10:15

Message:
This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for a detailed example:

http://www.python.org/cgi-bin/moinmoin/RepresentationError


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

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



From noreply@sourceforge.net  Mon May  6 19:04:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 May 2002 11:04:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-226586 ] Floating point is broken in Python 2.0
Message-ID: <E174mqZ-0005AM-00@usw-sf-web1.sourceforge.net>

Bugs item #226586, was opened at 2000-12-21 07:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=226586&group_id=5470

Category: IDLE
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Floating point is broken in Python 2.0

Initial Comment:
Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.6 -- press F1 for help
>>> p=0.6
>>> p
0.59999999999999998
>>> 

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

>Comment By: Tim Peters (tim_one)
Date: 2002-05-06 14:04

Message:
Logged In: YES 
user_id=31435

You may not like it, but it's not a bug.  Read the docs for 
a detailed explanation:

http://www.python.org/doc/current/tut/node14.html

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

Comment By: Michael Donegan (invader8)
Date: 2002-05-06 13:10

Message:
Logged In: YES 
user_id=537045

This is still a problem in
Python 2.2 (#1, Dec 31 2001, 15:21:18)

It is a bug. Why would we expect that
the interactive prompt would behave
differently (worse) from using print?

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

Comment By: Tim Peters (tim_one)
Date: 2000-12-21 11:15

Message:
This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for a detailed example:

http://www.python.org/cgi-bin/moinmoin/RepresentationError


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

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



From noreply@sourceforge.net  Mon May  6 19:13:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 May 2002 11:13:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-552957 ] email.Utils.encode doesn't obey rfc2047
Message-ID: <E174mzQ-00049A-00@usw-sf-web3.sourceforge.net>

Bugs item #552957, was opened at 2002-05-06 14:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=552957&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ty Sarna (tsarna)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.Utils.encode doesn't obey rfc2047

Initial Comment:
The email.Utils.encoding function has two bugs, which
are somewhat related -- it fails to deal with long
input strings in two different ways.

First, newlines are not allowed in the middle of
rfc2047 encoded-words (per section 2: "[...] white
space characters MUST NOT appear between components of
an 'encoded-word'"). The _bencode and _qencode routines
that the encode function uses include newlines (or
"=\n"'s for quopri) in their output, and the encode
function doesn't remove them. Try encoding a long
string with 'q' for example. The resulting output will
contain one or more "= \n"'s, and the
email.Utils.decode function will not be able to parse it.

Patch:

*** Utils.py.orig       Mon May  6 13:17:05 2002
--- Utils.py    Mon May  6 13:18:16 2002
***************
*** 98,106 ****
      """Encode a string according to RFC 2047."""
      encoding = encoding.lower()
      if encoding == 'q':
!         estr = _qencode(s)
      elif encoding == 'b':
!         estr = _bencode(s)
      else:
          raise ValueError, 'Illegal encoding code: ' +
encoding
      return '=?%s?%s?%s?=' % (charset.lower(),
encoding, estr)
--- 98,106 ----
      """Encode a string according to RFC 2047."""
      encoding = encoding.lower()
      if encoding == 'q':
!         estr = _qencode(s).replace('=\n','')
      elif encoding == 'b':
!         estr = _bencode(s).replace('\n','')
      else:
          raise ValueError, 'Illegal encoding code: ' +
encoding
      return '=?%s?%s?%s?=' % (charset.lower(),
encoding, estr)

NOTE: The .replace()-ing should NOT be done in _bencode
and _quencode, because they're used other places where
their current behaviour is fine/expected.


Second problem: rfc2047 specifies that an encoded-word
 may be no longer than 75 characters (see section 2).
Also, in the case of, say, a From: header with high-bit
characters in the sender's name, you really want to
encode only the name, not the whole line, so that dumb
mail programs are able to recognize the email address
in the line without having to understand rfc2047.

Proposed solution: rename existing encode function
(with above patche applied) to encode_word. Add a new
encode function that splits the input string into a
list of words and whitespace runs.  Words are encoded
individually using encode_word() iff they are not pure
ascii. The results are then concatenated back with
original whitespace.

This still leaves the possibility that a single word,
when encoded, is longer than 75 characters. The
recommended practice in rfc2047 is to use multiple
encoded words separated by CRLF SPACE (or in our case ,
"\n "). 


Here is code that implements the above:

wsplit = re.compile('([ \n\t]+)').split


def encode(s, charset='iso-8859-1', encoding='q'):
    i = wsplit(s)
    o = []

    # max encoded-word length per rfc2047 section 2 is 75
    # 75 - len("=?" + "?" + "?" + "?=") == 69
    max_enc_text = 69 - len(charset) - len(encoding)
    if encoding == 'q':
        # 3 bytes per character worst case
        safe_wlen = max_enc_text / 3
    elif encoding == 'b':
        safe_wlen = (max_enc_text * 6) / 8
    else:
        safe_wlen = max_enc_text # ?

    for w in i:
        if w[0] in " \n\t":
            o.append(w)
        else:
            try:
                o.append(w.encode('ascii'))
            except:
                ew = encode_word(w, charset, encoding)
                while len(ew) > 75:
                   
o.append(encode_word(w[:safe_wlen],charset,encoding)+"\n ")
                    w = w[safe_wlen:]
                    ew = encode_word(w, charset, encoding)
                o.append(ew)

    return ''.join(o)


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

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



From noreply@sourceforge.net  Mon May  6 21:27:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 May 2002 13:27:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E174p4n-0006BK-00@usw-sf-web2.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

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



From noreply@sourceforge.net  Mon May  6 21:28:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 May 2002 13:28:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E174p5k-0006CD-00@usw-sf-web2.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

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



From noreply@sourceforge.net  Mon May  6 22:33:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 May 2002 14:33:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-553031 ] StringIO uses wrong length on non-string
Message-ID: <E174q6u-0006fX-00@usw-sf-web4.sourceforge.net>

Bugs item #553031, was opened at 2002-05-06 17:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553031&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Holden (holdenweb)
Assigned to: Nobody/Anonymous (nobody)
Summary: StringIO uses wrong length on non-string

Initial Comment:
Brian Quinlan points out that StringIO behaves oddly 
when the argument to the creation is not of a string 
type. This is because of a bug in the __init__() 
method. The following patch appears to fix it:

Index: StringIO.py
=======================================================
============
RCS 
file: /cvsroot/python/python/dist/src/Lib/StringIO.py,v
retrieving revision 1.22
diff -r1.22 StringIO.py
45c45
<         self.len = len(buf)
---
>         self.len = len(self.buf)

In Brian's original example he was calling StringIO 
with a list argument, and getting the wrong number of 
characters back.




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

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



From noreply@sourceforge.net  Tue May  7 03:35:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 May 2002 19:35:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-408271 ] crash in shelve module
Message-ID: <E174uov-0001hG-00@usw-sf-web2.sourceforge.net>

Bugs item #408271, was opened at 2001-03-14 05:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: crash in shelve module

Initial Comment:
While using shelve module on SGI
sloth 271> uname -a
IRIX64 sloth 6.5 04191225 IP27

my python program crashes and
I am getting following error message:

  File "/usr/local/lib/python1.5/shelve.py", line 71,
in __setitem__
    self.dict[key] = f.getvalue()
bsddb.error: (0, 'Error')

At the time the size of the "shelve" file was quite big
(maybe this is a problem ?)
sloth 267> ls -lt *shelve
-rw-r--r--    1 ryszard  cdiApps   85778432 Mar 13
12:27 recap_mddr.shelve


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

Comment By: Garth T Kidd (gtk)
Date: 2002-05-07 12:35

Message:
Logged In: YES 
user_id=59803

If bssdb is broken, shelve should use anydbm and bsddb 
should be deprecated. Precedence: regexp.

ActivePython 2.2.0 Build 221 (ActiveState Corp.) based on
Python 2.2 (#28, Mar 28 2002, 12:10:20) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import shelve
>>> s = shelve.open('temp.db', 'c')
>>> s.dict
<bsddb.bsddb object at 0x008A2D48>

Python 2.2.1 (#1, Apr 30 2002, 17:02:05)
[GCC 2.95.3 20010315 (SuSE)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import shelve
>>> s = shelve.open('temp.db', 'c')
>>> s.dict
<bsddb.bsddb object at 0x815a388>
>>>



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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-07 01:13

Message:
Logged In: YES 
user_id=12800

I'd highly suggest that any serious work with BerkeleyDB be
done with pybsddb and a more modern version of Berkeley. 
The bsddb module that comes with Python 2.2 has serious
problems, including not being able to link on some *nix
distros.  Also BDB 1.85 is way way old and has many known
problems. 

I ran the deadlybloddyserious example using BDB 3.11 and
pybsddb 3.0 and it passed with flying colors.  See
www.sleepycat.com for the latest BDB's and pybsddb.sf.net
for the latest Python wrappers.

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

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 17:55

Message:
Logged In: YES 
user_id=59803

You might want to re-open this one, Barry. The problem 
seems to be with any large number of bsddb inserts, which 
can also be triggered by shelve. See: 

http://www.deadlybloodyserious.com/Python/2002/05/06.html

http://bugs.activestate.com/show_bug.cgi?id=10242 

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-03-19 03:10

Message:
Logged In: YES 
user_id=12800

Besides, this was submitted by "anonymous" and the only clue
to the identity of the original poster is in the ls output. 
Unfortunately, I'm not prepared to spam all the Ryszard's in
my name database. :)

I'm closing this report until/unless we get more
information.

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

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

Message:
Logged In: YES 
user_id=31435

Assigned to Barry because there's not enough info here to 
do anything about it <wink>.

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

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



From noreply@sourceforge.net  Tue May  7 04:49:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 May 2002 20:49:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-408271 ] crash in shelve module
Message-ID: <E174vyI-00030d-00@usw-sf-web1.sourceforge.net>

Bugs item #408271, was opened at 2001-03-14 05:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: crash in shelve module

Initial Comment:
While using shelve module on SGI
sloth 271> uname -a
IRIX64 sloth 6.5 04191225 IP27

my python program crashes and
I am getting following error message:

  File "/usr/local/lib/python1.5/shelve.py", line 71,
in __setitem__
    self.dict[key] = f.getvalue()
bsddb.error: (0, 'Error')

At the time the size of the "shelve" file was quite big
(maybe this is a problem ?)
sloth 267> ls -lt *shelve
-rw-r--r--    1 ryszard  cdiApps   85778432 Mar 13
12:27 recap_mddr.shelve


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

Comment By: Garth T Kidd (gtk)
Date: 2002-05-07 13:49

Message:
Logged In: YES 
user_id=59803

Submitted patch #553108.

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

Comment By: Garth T Kidd (gtk)
Date: 2002-05-07 12:35

Message:
Logged In: YES 
user_id=59803

If bssdb is broken, shelve should use anydbm and bsddb 
should be deprecated. Precedence: regexp.

ActivePython 2.2.0 Build 221 (ActiveState Corp.) based on
Python 2.2 (#28, Mar 28 2002, 12:10:20) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import shelve
>>> s = shelve.open('temp.db', 'c')
>>> s.dict
<bsddb.bsddb object at 0x008A2D48>

Python 2.2.1 (#1, Apr 30 2002, 17:02:05)
[GCC 2.95.3 20010315 (SuSE)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import shelve
>>> s = shelve.open('temp.db', 'c')
>>> s.dict
<bsddb.bsddb object at 0x815a388>
>>>



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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-07 01:13

Message:
Logged In: YES 
user_id=12800

I'd highly suggest that any serious work with BerkeleyDB be
done with pybsddb and a more modern version of Berkeley. 
The bsddb module that comes with Python 2.2 has serious
problems, including not being able to link on some *nix
distros.  Also BDB 1.85 is way way old and has many known
problems. 

I ran the deadlybloddyserious example using BDB 3.11 and
pybsddb 3.0 and it passed with flying colors.  See
www.sleepycat.com for the latest BDB's and pybsddb.sf.net
for the latest Python wrappers.

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

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 17:55

Message:
Logged In: YES 
user_id=59803

You might want to re-open this one, Barry. The problem 
seems to be with any large number of bsddb inserts, which 
can also be triggered by shelve. See: 

http://www.deadlybloodyserious.com/Python/2002/05/06.html

http://bugs.activestate.com/show_bug.cgi?id=10242 

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-03-19 03:10

Message:
Logged In: YES 
user_id=12800

Besides, this was submitted by "anonymous" and the only clue
to the identity of the original poster is in the ls output. 
Unfortunately, I'm not prepared to spam all the Ryszard's in
my name database. :)

I'm closing this report until/unless we get more
information.

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

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

Message:
Logged In: YES 
user_id=31435

Assigned to Barry because there's not enough info here to 
do anything about it <wink>.

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

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



From noreply@sourceforge.net  Tue May  7 04:56:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 May 2002 20:56:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-408271 ] crash in shelve module
Message-ID: <E174w5L-0002C5-00@usw-sf-web4.sourceforge.net>

Bugs item #408271, was opened at 2001-03-14 05:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: crash in shelve module

Initial Comment:
While using shelve module on SGI
sloth 271> uname -a
IRIX64 sloth 6.5 04191225 IP27

my python program crashes and
I am getting following error message:

  File "/usr/local/lib/python1.5/shelve.py", line 71,
in __setitem__
    self.dict[key] = f.getvalue()
bsddb.error: (0, 'Error')

At the time the size of the "shelve" file was quite big
(maybe this is a problem ?)
sloth 267> ls -lt *shelve
-rw-r--r--    1 ryszard  cdiApps   85778432 Mar 13
12:27 recap_mddr.shelve


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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-07 13:56

Message:
Logged In: YES 
user_id=29957

Barry, if it's known to be stuffed, why is it
still there?
Is there an open bug report for how it's busted?
A bunch of stuff that depends on getting "a db
storage" is going to use bsddb...


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

Comment By: Garth T Kidd (gtk)
Date: 2002-05-07 13:49

Message:
Logged In: YES 
user_id=59803

Submitted patch #553108.

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

Comment By: Garth T Kidd (gtk)
Date: 2002-05-07 12:35

Message:
Logged In: YES 
user_id=59803

If bssdb is broken, shelve should use anydbm and bsddb 
should be deprecated. Precedence: regexp.

ActivePython 2.2.0 Build 221 (ActiveState Corp.) based on
Python 2.2 (#28, Mar 28 2002, 12:10:20) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import shelve
>>> s = shelve.open('temp.db', 'c')
>>> s.dict
<bsddb.bsddb object at 0x008A2D48>

Python 2.2.1 (#1, Apr 30 2002, 17:02:05)
[GCC 2.95.3 20010315 (SuSE)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import shelve
>>> s = shelve.open('temp.db', 'c')
>>> s.dict
<bsddb.bsddb object at 0x815a388>
>>>



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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-07 01:13

Message:
Logged In: YES 
user_id=12800

I'd highly suggest that any serious work with BerkeleyDB be
done with pybsddb and a more modern version of Berkeley. 
The bsddb module that comes with Python 2.2 has serious
problems, including not being able to link on some *nix
distros.  Also BDB 1.85 is way way old and has many known
problems. 

I ran the deadlybloddyserious example using BDB 3.11 and
pybsddb 3.0 and it passed with flying colors.  See
www.sleepycat.com for the latest BDB's and pybsddb.sf.net
for the latest Python wrappers.

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

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 17:55

Message:
Logged In: YES 
user_id=59803

You might want to re-open this one, Barry. The problem 
seems to be with any large number of bsddb inserts, which 
can also be triggered by shelve. See: 

http://www.deadlybloodyserious.com/Python/2002/05/06.html

http://bugs.activestate.com/show_bug.cgi?id=10242 

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-03-19 03:10

Message:
Logged In: YES 
user_id=12800

Besides, this was submitted by "anonymous" and the only clue
to the identity of the original poster is in the ls output. 
Unfortunately, I'm not prepared to spam all the Ryszard's in
my name database. :)

I'm closing this report until/unless we get more
information.

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

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

Message:
Logged In: YES 
user_id=31435

Assigned to Barry because there's not enough info here to 
do anything about it <wink>.

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

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



From noreply@sourceforge.net  Tue May  7 12:39:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 04:39:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-519621 ] __slots__ may lead to undetected cycles
Message-ID: <E1753JR-0007Jm-00@usw-sf-web4.sourceforge.net>

Bugs item #519621, was opened at 2002-02-18 16:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=519621&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Martin v. Löwis (loewis)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ may lead to undetected cycles

Initial Comment:
Please see the attached script. It should print

Deleting
Deleted
done

[and actually does when you remove the cycle], but prints

Deleting
done



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

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



From noreply@sourceforge.net  Tue May  7 13:25:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 05:25:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-551504 ] python -v sometimes fails to find init
Message-ID: <E17542M-0007of-00@usw-sf-web4.sourceforge.net>

Bugs item #551504, was opened at 2002-05-02 13:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551504&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Joseph Winston (josephwinston)
Assigned to: Nobody/Anonymous (nobody)
Summary: python -v sometimes fails to find init

Initial Comment:
On HP-UX 11 python -v sometimes fails to find the init 
method for a
dynamic library.  An instance of this can be found 
when trying to load
libsip.  A possible work around is the following patch:

diff -c -c -r1.1 dynload_hpux.c
*** dynload_hpux.c	2 May 2002 16:04:08 -0000
	1.1
--- dynload_hpux.c	2 May 2002 17:12:01 -0000
***************
*** 29,35 ****
  
  	flags = BIND_FIRST | BIND_DEFERRED;
  	if (Py_VerboseFlag) {
! 		flags = DYNAMIC_PATH | BIND_FIRST | 
BIND_IMMEDIATE |
  			BIND_NONFATAL | BIND_VERBOSE;
  		printf("shl_load %s\n",pathname);
  	}
--- 29,35 ----
  
  	flags = BIND_FIRST | BIND_DEFERRED;
  	if (Py_VerboseFlag) {
! 		flags = BIND_FIRST | BIND_IMMEDIATE |
  			BIND_NONFATAL | BIND_VERBOSE;
  		printf("shl_load %s\n",pathname);
  	}

I do not know why DYNAMIC_PATH is causing the loading 
to fail since
the man page for shl_load says:

DYNAMIC_PATH Allow the loader todynamically search for 
the library
specified by the path argument.  The directories to be 
searched are
determined by the +s and +b options of the ld command 
used when the
program was linked.  On PA64, this is enabled by 
default if ld +compat
was not specified.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-07 08:25

Message:
Logged In: YES 
user_id=6380

The origin for this code is lost in history. I propose to
accept this patch, since it's strange that in verbose mode
the dynamic library search semantics should be any different
than normally.

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

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



From noreply@sourceforge.net  Tue May  7 13:26:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 05:26:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-551551 ] type->tp_mro NULL, typeobject.c:1217
Message-ID: <E17542p-0007pC-00@usw-sf-web4.sourceforge.net>

Bugs item #551551, was opened at 2002-05-02 15:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551551&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Luke Kenneth Casson Leighton (lkcl)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: type->tp_mro NULL, typeobject.c:1217

Initial Comment:
a segfault occurs at line 1217 in typeobject.c due to
type->tp_mro being NULL.

the following small testcode example repros the case:

class UserLong(object):

    def __pow__(self, *args):
        print "don't have to do anything, just declare
the function"
        print "putting def __pow__(self, x, y): doesn't
affect segfault"

print pow(5, UserLong(3L), 26)


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

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



From noreply@sourceforge.net  Tue May  7 13:42:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 05:42:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-553242 ] make test failed
Message-ID: <E1754IE-0008Qd-00@usw-sf-web2.sourceforge.net>

Bugs item #553242, was opened at 2002-05-07 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553242&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Anh-Thu Tran (atran4)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed

Initial Comment:
Hi,

I have make test failed on test_locale.  Please help.
Thank you.

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

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



From noreply@sourceforge.net  Tue May  7 14:11:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 06:11:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-553242 ] make test failed
Message-ID: <E1754k8-0000RE-00@usw-sf-web1.sourceforge.net>

Bugs item #553242, was opened at 2002-05-07 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553242&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Anh-Thu Tran (atran4)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed

Initial Comment:
Hi,

I have make test failed on test_locale.  Please help.
Thank you.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-07 15:11

Message:
Logged In: YES 
user_id=21627

Please report details: What operating system, what Python
release, how does it fail?

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

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



From noreply@sourceforge.net  Tue May  7 14:14:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 06:14:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-551551 ] type->tp_mro NULL, typeobject.c:1217
Message-ID: <E1754nM-0000Mb-00@usw-sf-web2.sourceforge.net>

Bugs item #551551, was opened at 2002-05-02 19:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551551&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Luke Kenneth Casson Leighton (lkcl)
>Assigned to: Michael Hudson (mwh)
Summary: type->tp_mro NULL, typeobject.c:1217

Initial Comment:
a segfault occurs at line 1217 in typeobject.c due to
type->tp_mro being NULL.

the following small testcode example repros the case:

class UserLong(object):

    def __pow__(self, *args):
        print "don't have to do anything, just declare
the function"
        print "putting def __pow__(self, x, y): doesn't
affect segfault"

print pow(5, UserLong(3L), 26)


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

>Comment By: Michael Hudson (mwh)
Date: 2002-05-07 13:14

Message:
Logged In: YES 
user_id=6656

Oops, I forgot to mark this as a dup of

[ 551412 ] possible to fail to calc mro's

(there's a touch more info in that report).

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

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



From noreply@sourceforge.net  Tue May  7 14:27:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 06:27:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-553262 ] [RefMan] Special status of "as"
Message-ID: <E1754zz-0008G7-00@usw-sf-web3.sourceforge.net>

Bugs item #553262, was opened at 2002-05-07 09:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553262&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: [RefMan] Special status of "as"

Initial Comment:
The special status of "as" in import statements needs
to be acknowledged in the list of keywords (RefMan 2.3.1).

(Based on note sent to python-docs.)

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

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



From noreply@sourceforge.net  Tue May  7 14:51:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 06:51:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-553242 ] make test failed
Message-ID: <E1755Mx-00006A-00@usw-sf-web3.sourceforge.net>

Bugs item #553242, was opened at 2002-05-07 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553242&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Anh-Thu Tran (atran4)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed

Initial Comment:
Hi,

I have make test failed on test_locale.  Please help.
Thank you.

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

>Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 13:51

Message:
Logged In: YES 
user_id=537870

I tried to install python 2.2.1 on Sun OS 5.6.  I got the error messages when running "make test"
1 test failed:
    test_locale
25 tests skipped:
    test_al test_audioop test_bsddb test_cd test_cl test_curses
    test_dl test_gdbm test_gl test_gzip test_imgfile test_largefile
    test_linuxaudiodev test_minidom test_ntpath test_openpty
    test_pyexpat test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_winreg test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


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

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

Message:
Logged In: YES 
user_id=21627

Please report details: What operating system, what Python
release, how does it fail?

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

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



From noreply@sourceforge.net  Tue May  7 17:16:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 09:16:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-553242 ] make test failed
Message-ID: <E1757dV-0002cf-00@usw-sf-web1.sourceforge.net>

Bugs item #553242, was opened at 2002-05-07 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553242&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Anh-Thu Tran (atran4)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed

Initial Comment:
Hi,

I have make test failed on test_locale.  Please help.
Thank you.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-07 18:16

Message:
Logged In: YES 
user_id=21627

Can you please run

./python Lib/test/test_locale.py

in your build directory, and report the output?


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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 15:51

Message:
Logged In: YES 
user_id=537870

I tried to install python 2.2.1 on Sun OS 5.6.  I got the error messages when running "make test"
1 test failed:
    test_locale
25 tests skipped:
    test_al test_audioop test_bsddb test_cd test_cl test_curses
    test_dl test_gdbm test_gl test_gzip test_imgfile test_largefile
    test_linuxaudiodev test_minidom test_ntpath test_openpty
    test_pyexpat test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_winreg test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


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

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

Message:
Logged In: YES 
user_id=21627

Please report details: What operating system, what Python
release, how does it fail?

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

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



From noreply@sourceforge.net  Tue May  7 17:23:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 09:23:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-553242 ] make test failed
Message-ID: <E1757kd-0002Vs-00@usw-sf-web2.sourceforge.net>

Bugs item #553242, was opened at 2002-05-07 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553242&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Anh-Thu Tran (atran4)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed

Initial Comment:
Hi,

I have make test failed on test_locale.  Please help.
Thank you.

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

>Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 16:23

Message:
Logged In: YES 
user_id=537870

Below are what I got when running the command you suggested:

root@cdesrv2:/tmp/Python-2.2.1
--> ./python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ... no
'%f' % 1024 == '1024.000000' != '1,024.000000'
'%f' % 102 =? '102.000000' ... yes
'%f' % -42 =? '-42.000000' ... yes
'%+f' % -42 =? '-42.000000' ... yes
'%20.f' % -42 =? '                 -42' ... yes
'%+10.f' % -4200 =? '    -4,200' ... no
'%+10.f' % -4200 == '    -4200' != '    -4,200'
'%-10.f' % 4200 =? '4,200     ' ... no
'%-10.f' % 4200 == '4200     ' != '4,200     '

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

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

Message:
Logged In: YES 
user_id=21627

Can you please run

./python Lib/test/test_locale.py

in your build directory, and report the output?


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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 13:51

Message:
Logged In: YES 
user_id=537870

I tried to install python 2.2.1 on Sun OS 5.6.  I got the error messages when running "make test"
1 test failed:
    test_locale
25 tests skipped:
    test_al test_audioop test_bsddb test_cd test_cl test_curses
    test_dl test_gdbm test_gl test_gzip test_imgfile test_largefile
    test_linuxaudiodev test_minidom test_ntpath test_openpty
    test_pyexpat test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_winreg test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


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

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

Message:
Logged In: YES 
user_id=21627

Please report details: What operating system, what Python
release, how does it fail?

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

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



From noreply@sourceforge.net  Tue May  7 17:27:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 09:27:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-553242 ] make test failed
Message-ID: <E1757oH-0001ve-00@usw-sf-web3.sourceforge.net>

Bugs item #553242, was opened at 2002-05-07 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553242&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Anh-Thu Tran (atran4)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed

Initial Comment:
Hi,

I have make test failed on test_locale.  Please help.
Thank you.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-07 18:27

Message:
Logged In: YES 
user_id=21627

Thanks for reporting those details.

This is a known bug in Solaris 2.6: Even though it supports
the en_US locale, it incorrectly reports grouping
information. This bug has been fixed in later Solaris releases.

You don't need to worry about it; it is not a bug in Python.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 18:23

Message:
Logged In: YES 
user_id=537870

Below are what I got when running the command you suggested:

root@cdesrv2:/tmp/Python-2.2.1
--> ./python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ... no
'%f' % 1024 == '1024.000000' != '1,024.000000'
'%f' % 102 =? '102.000000' ... yes
'%f' % -42 =? '-42.000000' ... yes
'%+f' % -42 =? '-42.000000' ... yes
'%20.f' % -42 =? '                 -42' ... yes
'%+10.f' % -4200 =? '    -4,200' ... no
'%+10.f' % -4200 == '    -4200' != '    -4,200'
'%-10.f' % 4200 =? '4,200     ' ... no
'%-10.f' % 4200 == '4200     ' != '4,200     '

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

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

Message:
Logged In: YES 
user_id=21627

Can you please run

./python Lib/test/test_locale.py

in your build directory, and report the output?


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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 15:51

Message:
Logged In: YES 
user_id=537870

I tried to install python 2.2.1 on Sun OS 5.6.  I got the error messages when running "make test"
1 test failed:
    test_locale
25 tests skipped:
    test_al test_audioop test_bsddb test_cd test_cl test_curses
    test_dl test_gdbm test_gl test_gzip test_imgfile test_largefile
    test_linuxaudiodev test_minidom test_ntpath test_openpty
    test_pyexpat test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_winreg test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


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

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

Message:
Logged In: YES 
user_id=21627

Please report details: What operating system, what Python
release, how does it fail?

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

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



From noreply@sourceforge.net  Tue May  7 17:48:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 09:48:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-553242 ] make test failed
Message-ID: <E17588x-0002CB-00@usw-sf-web3.sourceforge.net>

Bugs item #553242, was opened at 2002-05-07 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553242&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Anh-Thu Tran (atran4)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed

Initial Comment:
Hi,

I have make test failed on test_locale.  Please help.
Thank you.

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

>Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 16:48

Message:
Logged In: YES 
user_id=537870

I also got the "make test" error when trying install Python 2.2.1 on Tru64 version 4.0. Please help.

1 test failed:
    test_format
23 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_ntpath test_rgbimg test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file test_winreg
    test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.
*** Exit 1
Stop.


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

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

Message:
Logged In: YES 
user_id=21627

Thanks for reporting those details.

This is a known bug in Solaris 2.6: Even though it supports
the en_US locale, it incorrectly reports grouping
information. This bug has been fixed in later Solaris releases.

You don't need to worry about it; it is not a bug in Python.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 16:23

Message:
Logged In: YES 
user_id=537870

Below are what I got when running the command you suggested:

root@cdesrv2:/tmp/Python-2.2.1
--> ./python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ... no
'%f' % 1024 == '1024.000000' != '1,024.000000'
'%f' % 102 =? '102.000000' ... yes
'%f' % -42 =? '-42.000000' ... yes
'%+f' % -42 =? '-42.000000' ... yes
'%20.f' % -42 =? '                 -42' ... yes
'%+10.f' % -4200 =? '    -4,200' ... no
'%+10.f' % -4200 == '    -4200' != '    -4,200'
'%-10.f' % 4200 =? '4,200     ' ... no
'%-10.f' % 4200 == '4200     ' != '4,200     '

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

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

Message:
Logged In: YES 
user_id=21627

Can you please run

./python Lib/test/test_locale.py

in your build directory, and report the output?


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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 13:51

Message:
Logged In: YES 
user_id=537870

I tried to install python 2.2.1 on Sun OS 5.6.  I got the error messages when running "make test"
1 test failed:
    test_locale
25 tests skipped:
    test_al test_audioop test_bsddb test_cd test_cl test_curses
    test_dl test_gdbm test_gl test_gzip test_imgfile test_largefile
    test_linuxaudiodev test_minidom test_ntpath test_openpty
    test_pyexpat test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_winreg test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


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

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

Message:
Logged In: YES 
user_id=21627

Please report details: What operating system, what Python
release, how does it fail?

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

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



From noreply@sourceforge.net  Tue May  7 17:55:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 09:55:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-553242 ] make test failed
Message-ID: <E1758FN-0002Gx-00@usw-sf-web3.sourceforge.net>

Bugs item #553242, was opened at 2002-05-07 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553242&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
>Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Anh-Thu Tran (atran4)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed

Initial Comment:
Hi,

I have make test failed on test_locale.  Please help.
Thank you.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 16:48

Message:
Logged In: YES 
user_id=537870

I also got the "make test" error when trying install Python 2.2.1 on Tru64 version 4.0. Please help.

1 test failed:
    test_format
23 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_ntpath test_rgbimg test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file test_winreg
    test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.
*** Exit 1
Stop.


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

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

Message:
Logged In: YES 
user_id=21627

Thanks for reporting those details.

This is a known bug in Solaris 2.6: Even though it supports
the en_US locale, it incorrectly reports grouping
information. This bug has been fixed in later Solaris releases.

You don't need to worry about it; it is not a bug in Python.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 16:23

Message:
Logged In: YES 
user_id=537870

Below are what I got when running the command you suggested:

root@cdesrv2:/tmp/Python-2.2.1
--> ./python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ... no
'%f' % 1024 == '1024.000000' != '1,024.000000'
'%f' % 102 =? '102.000000' ... yes
'%f' % -42 =? '-42.000000' ... yes
'%+f' % -42 =? '-42.000000' ... yes
'%20.f' % -42 =? '                 -42' ... yes
'%+10.f' % -4200 =? '    -4,200' ... no
'%+10.f' % -4200 == '    -4200' != '    -4,200'
'%-10.f' % 4200 =? '4,200     ' ... no
'%-10.f' % 4200 == '4200     ' != '4,200     '

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

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

Message:
Logged In: YES 
user_id=21627

Can you please run

./python Lib/test/test_locale.py

in your build directory, and report the output?


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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 13:51

Message:
Logged In: YES 
user_id=537870

I tried to install python 2.2.1 on Sun OS 5.6.  I got the error messages when running "make test"
1 test failed:
    test_locale
25 tests skipped:
    test_al test_audioop test_bsddb test_cd test_cl test_curses
    test_dl test_gdbm test_gl test_gzip test_imgfile test_largefile
    test_linuxaudiodev test_minidom test_ntpath test_openpty
    test_pyexpat test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_winreg test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


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

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

Message:
Logged In: YES 
user_id=21627

Please report details: What operating system, what Python
release, how does it fail?

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

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



From noreply@sourceforge.net  Tue May  7 18:18:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 10:18:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-553242 ] make test failed
Message-ID: <E1758bR-0002ow-00@usw-sf-web4.sourceforge.net>

Bugs item #553242, was opened at 2002-05-07 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553242&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Anh-Thu Tran (atran4)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed

Initial Comment:
Hi,

I have make test failed on test_locale.  Please help.
Thank you.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-07 19:18

Message:
Logged In: YES 
user_id=21627

Please run test_format separately and report the output.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 18:48

Message:
Logged In: YES 
user_id=537870

I also got the "make test" error when trying install Python 2.2.1 on Tru64 version 4.0. Please help.

1 test failed:
    test_format
23 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_ntpath test_rgbimg test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file test_winreg
    test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.
*** Exit 1
Stop.


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

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

Message:
Logged In: YES 
user_id=21627

Thanks for reporting those details.

This is a known bug in Solaris 2.6: Even though it supports
the en_US locale, it incorrectly reports grouping
information. This bug has been fixed in later Solaris releases.

You don't need to worry about it; it is not a bug in Python.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 18:23

Message:
Logged In: YES 
user_id=537870

Below are what I got when running the command you suggested:

root@cdesrv2:/tmp/Python-2.2.1
--> ./python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ... no
'%f' % 1024 == '1024.000000' != '1,024.000000'
'%f' % 102 =? '102.000000' ... yes
'%f' % -42 =? '-42.000000' ... yes
'%+f' % -42 =? '-42.000000' ... yes
'%20.f' % -42 =? '                 -42' ... yes
'%+10.f' % -4200 =? '    -4,200' ... no
'%+10.f' % -4200 == '    -4200' != '    -4,200'
'%-10.f' % 4200 =? '4,200     ' ... no
'%-10.f' % 4200 == '4200     ' != '4,200     '

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

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

Message:
Logged In: YES 
user_id=21627

Can you please run

./python Lib/test/test_locale.py

in your build directory, and report the output?


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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 15:51

Message:
Logged In: YES 
user_id=537870

I tried to install python 2.2.1 on Sun OS 5.6.  I got the error messages when running "make test"
1 test failed:
    test_locale
25 tests skipped:
    test_al test_audioop test_bsddb test_cd test_cl test_curses
    test_dl test_gdbm test_gl test_gzip test_imgfile test_largefile
    test_linuxaudiodev test_minidom test_ntpath test_openpty
    test_pyexpat test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_winreg test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


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

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

Message:
Logged In: YES 
user_id=21627

Please report details: What operating system, what Python
release, how does it fail?

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

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



From noreply@sourceforge.net  Tue May  7 18:35:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 10:35:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-553242 ] make test failed
Message-ID: <E1758sL-0003ZC-00@usw-sf-web1.sourceforge.net>

Bugs item #553242, was opened at 2002-05-07 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553242&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Anh-Thu Tran (atran4)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed

Initial Comment:
Hi,

I have make test failed on test_locale.  Please help.
Thank you.

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

>Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 17:35

Message:
Logged In: YES 
user_id=537870

OK.  I attached the output file when running ./python ./Lib/test/test_format.py.

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

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

Message:
Logged In: YES 
user_id=21627

Please run test_format separately and report the output.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 16:48

Message:
Logged In: YES 
user_id=537870

I also got the "make test" error when trying install Python 2.2.1 on Tru64 version 4.0. Please help.

1 test failed:
    test_format
23 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_ntpath test_rgbimg test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file test_winreg
    test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.
*** Exit 1
Stop.


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

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

Message:
Logged In: YES 
user_id=21627

Thanks for reporting those details.

This is a known bug in Solaris 2.6: Even though it supports
the en_US locale, it incorrectly reports grouping
information. This bug has been fixed in later Solaris releases.

You don't need to worry about it; it is not a bug in Python.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 16:23

Message:
Logged In: YES 
user_id=537870

Below are what I got when running the command you suggested:

root@cdesrv2:/tmp/Python-2.2.1
--> ./python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ... no
'%f' % 1024 == '1024.000000' != '1,024.000000'
'%f' % 102 =? '102.000000' ... yes
'%f' % -42 =? '-42.000000' ... yes
'%+f' % -42 =? '-42.000000' ... yes
'%20.f' % -42 =? '                 -42' ... yes
'%+10.f' % -4200 =? '    -4,200' ... no
'%+10.f' % -4200 == '    -4200' != '    -4,200'
'%-10.f' % 4200 =? '4,200     ' ... no
'%-10.f' % 4200 == '4200     ' != '4,200     '

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

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

Message:
Logged In: YES 
user_id=21627

Can you please run

./python Lib/test/test_locale.py

in your build directory, and report the output?


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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 13:51

Message:
Logged In: YES 
user_id=537870

I tried to install python 2.2.1 on Sun OS 5.6.  I got the error messages when running "make test"
1 test failed:
    test_locale
25 tests skipped:
    test_al test_audioop test_bsddb test_cd test_cl test_curses
    test_dl test_gdbm test_gl test_gzip test_imgfile test_largefile
    test_linuxaudiodev test_minidom test_ntpath test_openpty
    test_pyexpat test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_winreg test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


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

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

Message:
Logged In: YES 
user_id=21627

Please report details: What operating system, what Python
release, how does it fail?

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

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



From noreply@sourceforge.net  Tue May  7 19:41:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 11:41:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-553242 ] make test failed
Message-ID: <E1759uG-0004LU-00@usw-sf-web1.sourceforge.net>

Bugs item #553242, was opened at 2002-05-07 08:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553242&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Anh-Thu Tran (atran4)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed

Initial Comment:
Hi,

I have make test failed on test_locale.  Please help.
Thank you.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-05-07 14:41

Message:
Logged In: YES 
user_id=31435

That one is a known bug in the Tru64 C library -- it 
doesn't handle C "%o" formats correctly in all cases.  You 
can report it as a bug to your compiler supplier, but it's 
not a bug in Python.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 13:35

Message:
Logged In: YES 
user_id=537870

OK.  I attached the output file when running ./python ./Lib/test/test_format.py.

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

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

Message:
Logged In: YES 
user_id=21627

Please run test_format separately and report the output.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 12:48

Message:
Logged In: YES 
user_id=537870

I also got the "make test" error when trying install Python 2.2.1 on Tru64 version 4.0. Please help.

1 test failed:
    test_format
23 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_ntpath test_rgbimg test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file test_winreg
    test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.
*** Exit 1
Stop.


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

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

Message:
Logged In: YES 
user_id=21627

Thanks for reporting those details.

This is a known bug in Solaris 2.6: Even though it supports
the en_US locale, it incorrectly reports grouping
information. This bug has been fixed in later Solaris releases.

You don't need to worry about it; it is not a bug in Python.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 12:23

Message:
Logged In: YES 
user_id=537870

Below are what I got when running the command you suggested:

root@cdesrv2:/tmp/Python-2.2.1
--> ./python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ... no
'%f' % 1024 == '1024.000000' != '1,024.000000'
'%f' % 102 =? '102.000000' ... yes
'%f' % -42 =? '-42.000000' ... yes
'%+f' % -42 =? '-42.000000' ... yes
'%20.f' % -42 =? '                 -42' ... yes
'%+10.f' % -4200 =? '    -4,200' ... no
'%+10.f' % -4200 == '    -4200' != '    -4,200'
'%-10.f' % 4200 =? '4,200     ' ... no
'%-10.f' % 4200 == '4200     ' != '4,200     '

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

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

Message:
Logged In: YES 
user_id=21627

Can you please run

./python Lib/test/test_locale.py

in your build directory, and report the output?


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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 09:51

Message:
Logged In: YES 
user_id=537870

I tried to install python 2.2.1 on Sun OS 5.6.  I got the error messages when running "make test"
1 test failed:
    test_locale
25 tests skipped:
    test_al test_audioop test_bsddb test_cd test_cl test_curses
    test_dl test_gdbm test_gl test_gzip test_imgfile test_largefile
    test_linuxaudiodev test_minidom test_ntpath test_openpty
    test_pyexpat test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_winreg test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


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

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

Message:
Logged In: YES 
user_id=21627

Please report details: What operating system, what Python
release, how does it fail?

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

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



From noreply@sourceforge.net  Tue May  7 21:31:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 13:31:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E175BcA-0005QF-00@usw-sf-web2.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 22:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 22:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Wed May  8 00:48:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 16:48:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-553512 ] cPickle dies on short reads
Message-ID: <E175EhR-0007b8-00@usw-sf-web2.sourceforge.net>

Bugs item #553512, was opened at 2002-05-07 19:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553512&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle dies on short reads

Initial Comment:
I discovered that cPickle can report various failures
when reading from a file object created by a socket's
makefile() method, probably due to not dealing
correctly with short reads. I've seen this in 2.1.3 so
I believe it must be widespread.

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

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



From noreply@sourceforge.net  Wed May  8 04:38:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 20:38:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E175IHY-0000lz-00@usw-sf-web4.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 16:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Wed May  8 04:42:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 20:42:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E175IL8-0001JW-00@usw-sf-web1.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Jarek Sacha (jsacha)
Date: 2002-05-07 23:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 16:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Wed May  8 04:43:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 May 2002 20:43:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E175IMR-0001CU-00@usw-sf-web2.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
>Priority: 8
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-07 23:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 16:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Wed May  8 08:01:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 May 2002 00:01:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-553242 ] make test failed
Message-ID: <E175LSF-00036x-00@usw-sf-web2.sourceforge.net>

Bugs item #553242, was opened at 2002-05-07 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553242&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
>Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Anh-Thu Tran (atran4)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed

Initial Comment:
Hi,

I have make test failed on test_locale.  Please help.
Thank you.

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

Comment By: Tim Peters (tim_one)
Date: 2002-05-07 20:41

Message:
Logged In: YES 
user_id=31435

That one is a known bug in the Tru64 C library -- it 
doesn't handle C "%o" formats correctly in all cases.  You 
can report it as a bug to your compiler supplier, but it's 
not a bug in Python.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 19:35

Message:
Logged In: YES 
user_id=537870

OK.  I attached the output file when running ./python ./Lib/test/test_format.py.

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

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

Message:
Logged In: YES 
user_id=21627

Please run test_format separately and report the output.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 18:48

Message:
Logged In: YES 
user_id=537870

I also got the "make test" error when trying install Python 2.2.1 on Tru64 version 4.0. Please help.

1 test failed:
    test_format
23 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_ntpath test_rgbimg test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file test_winreg
    test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.
*** Exit 1
Stop.


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

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

Message:
Logged In: YES 
user_id=21627

Thanks for reporting those details.

This is a known bug in Solaris 2.6: Even though it supports
the en_US locale, it incorrectly reports grouping
information. This bug has been fixed in later Solaris releases.

You don't need to worry about it; it is not a bug in Python.

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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 18:23

Message:
Logged In: YES 
user_id=537870

Below are what I got when running the command you suggested:

root@cdesrv2:/tmp/Python-2.2.1
--> ./python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ... no
'%f' % 1024 == '1024.000000' != '1,024.000000'
'%f' % 102 =? '102.000000' ... yes
'%f' % -42 =? '-42.000000' ... yes
'%+f' % -42 =? '-42.000000' ... yes
'%20.f' % -42 =? '                 -42' ... yes
'%+10.f' % -4200 =? '    -4,200' ... no
'%+10.f' % -4200 == '    -4200' != '    -4,200'
'%-10.f' % 4200 =? '4,200     ' ... no
'%-10.f' % 4200 == '4200     ' != '4,200     '

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

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

Message:
Logged In: YES 
user_id=21627

Can you please run

./python Lib/test/test_locale.py

in your build directory, and report the output?


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

Comment By: Anh-Thu Tran (atran4)
Date: 2002-05-07 15:51

Message:
Logged In: YES 
user_id=537870

I tried to install python 2.2.1 on Sun OS 5.6.  I got the error messages when running "make test"
1 test failed:
    test_locale
25 tests skipped:
    test_al test_audioop test_bsddb test_cd test_cl test_curses
    test_dl test_gdbm test_gl test_gzip test_imgfile test_largefile
    test_linuxaudiodev test_minidom test_ntpath test_openpty
    test_pyexpat test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_winreg test_winsound test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


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

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

Message:
Logged In: YES 
user_id=21627

Please report details: What operating system, what Python
release, how does it fail?

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

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



From noreply@sourceforge.net  Wed May  8 09:45:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 May 2002 01:45:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E175N4L-0003iO-00@usw-sf-web3.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 22:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 8
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-05-08 10:45

Message:
Logged In: YES 
user_id=45365

The test for IPv6 support on your machine actually tries to run a program that uses IPv6. So, could it be that you have IPv6 support partially installed? For instance, you have the headers (does AF_INET6 occur anywhere in <sys/socket.h> or any flie it includes?) but not the corresponding C library.

This guess is easy to check: try a "./configure --disable-ipv6". If that works fine then the oabove is your problem, probably, and you also have a  workaround:-)

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-08 05:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 22:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Wed May  8 14:22:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 May 2002 06:22:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-551912 ] mimify.mime_decode_header only latin1
Message-ID: <E175ROL-0007eT-00@usw-sf-web1.sourceforge.net>

Bugs item #551912, was opened at 2002-05-03 18:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551912&group_id=5470

Category: Python Library
Group: None
Status: Open
>Resolution: Wont Fix
>Priority: 3
Submitted By: Gerhard Häring (ghaering)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: mimify.mime_decode_header only latin1

Initial Comment:
This function only works for iso-8859-1. If you look at
the regex it uses, it's also clear why. I'll try to
come up with a patch.

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

>Comment By: Gerhard Häring (ghaering)
Date: 2002-05-08 15:22

Message:
Logged In: YES 
user_id=163326

Assigning to Fred Drake and lowering priority and marking
WONTFIX.

Fred, do you think that a note should be added to the docs
about the weaknesses of the mimify module and that the new
stuff from the email module should be used instead?

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-03 19:05

Message:
Logged In: YES 
user_id=12800

Yup, I agree.  For a while, I've wanted to deprecate mimify,
(the api to) rfc822, MIMEWriter, and mimetools.  I think the
hangup on doing this for Python 2.2 was to try to come up
with recipes for folks to migrate their code to the email
package.  I don't have time to do that though.  Maybe a faq
or howto on the email package could address these issues, so
that we can deprecate them for Python2.3 (but not remove
them for a long time, probably 2 years at least, see PEP 4)

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-05-03 18:48

Message:
Logged In: YES 
user_id=163326

Some of the code in this module is rather brain-dead (not
unicode-aware, hard-wired to latin1). Maybe it's best to
deprecate it or mark it as buggy in the docs. The new email
module provides better functions for this, anyway (info from
MvL):

email.Utils.decode (Python 2.2)

email.Header.decode_header (CVS)

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

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



From noreply@sourceforge.net  Wed May  8 16:00:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 May 2002 08:00:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-553736 ] thread_pthread.h on FreeBSD
Message-ID: <E175Svf-0008Re-00@usw-sf-web4.sourceforge.net>

Bugs item #553736, was opened at 2002-05-08 10:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553736&group_id=5470

Category: Threads
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Sawyers (zc_andrew)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread_pthread.h on FreeBSD

Initial Comment:
The pthread setstacksize of 64K is too small for 
FreeBSD in some cases (i.e. specifically when running 
Zope/CMF).  The attached diff has worked on 3+ 
different production sites; though the setting of the 
stacksize to 128K was WAG.  It might be possible to 
still overflow the stacksize, though in all the sites 
using this change are no longer having problems.
I've spoken with Fred about this on a few occassions...
Thanks,
Andrew

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

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



From noreply@sourceforge.net  Wed May  8 17:29:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 May 2002 09:29:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-547093 ] urllib/httplib vs corrupted tcp/ip stack
Message-ID: <E175UJZ-0001Co-00@usw-sf-web2.sourceforge.net>

Bugs item #547093, was opened at 2002-04-22 14:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547093&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Asle Pedersen (apederse)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib/httplib vs corrupted tcp/ip stack

Initial Comment:
I am trying to connect to a server (talouselama.fi) 
using urllib2. The server respond immediately after it 
has received the first package from the client 
(urllib2). Since httplib fragment http requests in a 
request package and subsequent header packages the 
server disregards any header information that is sendt 
using urllib2. I have used ethereal to trace the 
packages for the connection. I can provide a dump if 
necessary.

This problem may well be due to a corruptet tcp/ip 
stack at the server (talouselama.fi) but shouldn't 
urllib handle this if any other browser does. (lynx, 
explorer, opera - no exception)??

/Asle


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

>Comment By: Asle Pedersen (apederse)
Date: 2002-05-08 16:29

Message:
Logged In: YES 
user_id=152302

I do agree with you that is not httplib's responsibility to fix it. However my opinion is that at least we should try to find a work-around for this type of problem. I would hate being unable to connect to the site just because Python fails.

I have been looking into the possibility that the problem is related to which http version that is used. I used python2.0 in my original experiment and it issued http/1.0 requests. Later on I also tried to connect to the server directly using httplib and HTTPConnection to issue http/1.1 requests but it did not make any difference. The server still responded before httplib had finished its request.

Do you have any suggestions on a work-around?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 00:47

Message:
Logged In: YES 
user_id=6380

Can you explain what you think httplib is doing wrong?  Are
you saying that it should buffer the whole request until it
is ready to send it in a single send() request?  If so, I
don't think it is httplib's responsibility to fix this --
the server doesn't follow the HTTP protocol (which says
nothing about keeping things together in a single packet),
and its webmaster should be informed of the bug in his site.

Other browsers probably happen to send the whole request in
a single packet.

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

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



From noreply@sourceforge.net  Thu May  9 12:49:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 May 2002 04:49:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-554073 ] bug in telnetlib- 'opt' instead of 'c'
Message-ID: <E175mQ3-0004l1-00@usw-sf-web4.sourceforge.net>

Bugs item #554073, was opened at 2002-05-09 14:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554073&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christos Georgiou (tzot)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in telnetlib- 'opt' instead of 'c'

Initial Comment:
Line 424 of telnetlib.py is:
  self.msg('IAC %d not recognized' % ord(opt))
but this is wrong, because the variable that should be 
used is 'c', as such:
  self.msg('IAC %d not recognized' % ord(c))

Reference: http://groups.google.com/groups?selm=a4me60%
24brk%240%40216.39.172.122

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

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



From noreply@sourceforge.net  Thu May  9 12:50:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 May 2002 04:50:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-554073 ] bug in telnetlib- 'opt' instead of 'c'
Message-ID: <E175mRe-0004m1-00@usw-sf-web4.sourceforge.net>

Bugs item #554073, was opened at 2002-05-09 14:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554073&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 4
Submitted By: Christos Georgiou (tzot)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in telnetlib- 'opt' instead of 'c'

Initial Comment:
Line 424 of telnetlib.py is:
  self.msg('IAC %d not recognized' % ord(opt))
but this is wrong, because the variable that should be 
used is 'c', as such:
  self.msg('IAC %d not recognized' % ord(c))

Reference: http://groups.google.com/groups?selm=a4me60%
24brk%240%40216.39.172.122

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

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



From noreply@sourceforge.net  Thu May  9 15:23:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 May 2002 07:23:39 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-547481 ] In-place reverse() and sort() for slices
Message-ID: <E175opX-0006ZF-00@usw-sf-web4.sourceforge.net>

Feature Requests item #547481, was opened at 2002-04-23 11:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=547481&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Bender (bbender)
Assigned to: Nobody/Anonymous (nobody)
Summary: In-place reverse() and sort() for slices

Initial Comment:
In order to apply sort() or reverse() to only part of a
sequence (a slice), the following code seems to be
necessary:

	# a is a sequence
	tmp = s[m:n]
	tmp.sort()		# or tmp.reverse()
	s[m:n] = tmp

It would be much nicer to apply sort() or reverse() to
the slice directly:

	a[m:n].sort()

However, this does not work, since the slice returns a
new sequence object, on which sort() or reverse() will
work, instead of working on the slice in-place.
After sort() is done, the modified object will be
discarded, since it cannot be assigned to anything as
sort() and reverse() do not have a return value.

Therefore, the line above is accepted by the
interpreter even though it is completely useless.

My proposal is to change the semantics of applying
sort() and reverse() to slices such as to work in-place
on the slice, in stead of working on the new object
created by the slicing operation.

This would be similar to slice assignment, which also
does not create a new object.

Would this change require a PEP?

Bernhard Bender

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-09 16:23

Message:
Logged In: YES 
user_id=21627

I'm still not clear what it is that you are requesting. It
appears that you want

  x[m:n].reverse()

to be the reversed slice. One way to achieve this is to 
have .reverse return the object it operates on, instead of
None (which it currently returns). This has been rejected
before.

The other option is that

  x[m:n]

does not return a new list, but some kind of "slice object",
which has a reverse operation that has a different meaning
from the reverse operation of lists. This is a
backwards-incompatible change, since people rely on x[m:n]
returning a list if x is a list.

I can see no third approach to make this work. Can you?

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

Comment By: Bernhard Bender (bbender)
Date: 2002-04-25 14:45

Message:
Logged In: YES 
user_id=523837

I do not see this as a major change to the language:

1- slicing a[n:m] already has two different semantics
(creating a new object or referring to a slice of the
original sequence) depending on wether it is on the right or
left side of an assigment operator

2- statements like a[n:m].reverse() currently have no net
effect on any program, so they should not be used in any
well tested software.

3- I am not proposing to change the semantics of any current
use of slicing, especially a slice will still return a new
object.

The only change is for the application of in-place
operations like sort() and reverse() that currently make no
sense with slices.
Therefore, such change to the semantics of slicing should be
possible without doing harm to any existing program,
especially if an "import from __future__" is use to activate
the new semantics.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2002-04-24 00:17

Message:
Logged In: YES 
user_id=35752

This would take some deep magic to make work and would
be a fundamental change to the language.  lst[m:m] is an
expression that returns a new object.  The chances of this
change being accepted is about zero.

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

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



From noreply@sourceforge.net  Thu May  9 15:26:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 May 2002 07:26:00 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-533281 ] bsddb module needs iterators
Message-ID: <E175oro-0006bI-00@usw-sf-web4.sourceforge.net>

Feature Requests item #533281, was opened at 2002-03-21 21:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=533281&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael McFarland (sidlon)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb module needs iterators

Initial Comment:
  The hash, btree and record classes should have an iterator defined.  
The current first() and next() functions should make this a fairly 
simple change to bsddbmmodule.c.  This would allow:

  dbh = 
dbhash.open('mydb.db', 'r')
  for key in dbh:
    process(key, 
dbh[key])

and eliminate the temptation to use the following, 
which would be inadvisable for large databases:

  for key in 
dbh.keys():



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-09 16:26

Message:
Logged In: YES 
user_id=21627

This is unlikely to happen. More likely, bsddb will be
deprecated.

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

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



From noreply@sourceforge.net  Thu May  9 19:18:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 May 2002 11:18:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E175sUx-00010b-00@usw-sf-web1.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 8
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Jarek Sacha (jsacha)
Date: 2002-05-09 14:18

Message:
Logged In: YES 
user_id=32232

I tried running with --disable-ipv6 and got exactly the same
crash. I edited 'configure' and added extra instructions to
have some idea what is happening. I modified fragment at
line 4361 from:
============================================
if test "${enable_ipv6+set}" = set; then
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else

============================================

to 

============================================
if test "${enable_ipv6+set}" = set; then
  echo "l. 4362"
else
  echo "l. 4364"
fi
if test "${enable_ipv6+set}" = set; then
  echo "l. 4367"
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else
  echo "l. 4383"
===========================================

The interesting part is that "l.4362" or "l.4364" are
printed depending on option "--disable-ipv6" being used, as
expected. However, the program crashes befere either
"l.4367" or "l.4383" is printed. For instance if I run
"./configure --disable-ipv6" the last lines of output are:

checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... l. 4362
Segmentation fault (core dumped)

The modified config is attached. Maybe there is some problem
with interpreting the 'configure' itself?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-08 04:45

Message:
Logged In: YES 
user_id=45365

The test for IPv6 support on your machine actually tries to run a program that uses IPv6. So, could it be that you have IPv6 support partially installed? For instance, you have the headers (does AF_INET6 occur anywhere in <sys/socket.h> or any flie it includes?) but not the corresponding C library.

This guess is easy to check: try a "./configure --disable-ipv6". If that works fine then the oabove is your problem, probably, and you also have a  workaround:-)

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-07 23:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 16:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Thu May  9 21:38:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 May 2002 13:38:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-554257 ] typo
Message-ID: <E175ugL-0002dC-00@usw-sf-web1.sourceforge.net>

Bugs item #554257, was opened at 2002-05-09 20:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554257&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: typo

Initial Comment:
In section:
6.1.5 Process Management 
There is a missing space in the
description of waitpid(pid, options):
    "The details of this function differ on Unixand 
Windows."

Note "Unixand " -- There should be a space between 
Unix and and.





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

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



From noreply@sourceforge.net  Fri May 10 09:41:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 May 2002 01:41:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E1765xg-0001lq-00@usw-sf-web1.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 20:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 8
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Michael Hudson (mwh)
Date: 2002-05-10 08:41

Message:
Logged In: YES 
user_id=6656

Is there some way to tell which executable dumped the core
file?  It'd be "size core" on linux, dunno what on IRIX.

If it's /bin/sh, I'm not really sure what we can do...

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-09 18:18

Message:
Logged In: YES 
user_id=32232

I tried running with --disable-ipv6 and got exactly the same
crash. I edited 'configure' and added extra instructions to
have some idea what is happening. I modified fragment at
line 4361 from:
============================================
if test "${enable_ipv6+set}" = set; then
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else

============================================

to 

============================================
if test "${enable_ipv6+set}" = set; then
  echo "l. 4362"
else
  echo "l. 4364"
fi
if test "${enable_ipv6+set}" = set; then
  echo "l. 4367"
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else
  echo "l. 4383"
===========================================

The interesting part is that "l.4362" or "l.4364" are
printed depending on option "--disable-ipv6" being used, as
expected. However, the program crashes befere either
"l.4367" or "l.4383" is printed. For instance if I run
"./configure --disable-ipv6" the last lines of output are:

checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... l. 4362
Segmentation fault (core dumped)

The modified config is attached. Maybe there is some problem
with interpreting the 'configure' itself?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-08 08:45

Message:
Logged In: YES 
user_id=45365

The test for IPv6 support on your machine actually tries to run a program that uses IPv6. So, could it be that you have IPv6 support partially installed? For instance, you have the headers (does AF_INET6 occur anywhere in <sys/socket.h> or any flie it includes?) but not the corresponding C library.

This guess is easy to check: try a "./configure --disable-ipv6". If that works fine then the oabove is your problem, probably, and you also have a  workaround:-)

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-08 03:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 20:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Fri May 10 13:38:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 May 2002 05:38:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-554257 ] typo
Message-ID: <E1769f1-0004SU-00@usw-sf-web1.sourceforge.net>

Bugs item #554257, was opened at 2002-05-09 16:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554257&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: typo

Initial Comment:
In section:
6.1.5 Process Management 
There is a missing space in the
description of waitpid(pid, options):
    "The details of this function differ on Unixand 
Windows."

Note "Unixand " -- There should be a space between 
Unix and and.





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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-10 08:38

Message:
Logged In: YES 
user_id=3066

Does not apply to 2.2.x; waitpid() on Windows was not
present in the 2.2 series of releases.

Fixed in Doc/lib/libos.tex revision 1.85.

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

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



From noreply@sourceforge.net  Fri May 10 18:13:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 May 2002 10:13:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-548874 ] Lists do have __getitem__ method
Message-ID: <E176DxP-0007fa-00@usw-sf-web1.sourceforge.net>

Bugs item #548874, was opened at 2002-04-26 00:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548874&group_id=5470

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Kelly Gerber (kgerber)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Lists do have __getitem__ method

Initial Comment:
In the Python Reference Manual, Release 2.2.1, section
3.3 Special method names, first paragraph, it says"(The
reverse is not true--if x is a list object,
x.__getitem__(i) is not equivalent to x[i].)"

I do not think this is true any more since Python2.2,
because types now have special methods. They both seem
to produce the same result. Doesn't that make them
equivalent?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-05 15:57

Message:
Logged In: YES 
user_id=80475

Agreed.
Submitted documentation patch: www.python.org/sf/552468

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

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



From noreply@sourceforge.net  Fri May 10 20:27:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 May 2002 12:27:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-554644 ] Minor typo in README
Message-ID: <E176G2y-0000Es-00@usw-sf-web2.sourceforge.net>

Bugs item #554644, was opened at 2002-05-10 22:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554644&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joonas Paalasmaa (jpaal)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Minor typo in README 

Initial Comment:
There's propably a minor typo in README: ptread_* -> pthread_*.
I uploaded a patch.

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

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



From noreply@sourceforge.net  Fri May 10 20:38:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 May 2002 12:38:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-554645 ] Strange readline completer behaviour
Message-ID: <E176GDL-0000MQ-00@usw-sf-web2.sourceforge.net>

Bugs item #554645, was opened at 2002-05-10 22:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554645&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joonas Paalasmaa (jpaal)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange readline completer behaviour

Initial Comment:
I have enabled readline completing in my .pythonrc file to which PYTHONSTARTUP
points to. However, when I hit TAB twice in interactive mode, completer
displays the contents of the current directory, not Python's namespace.
I have built Python with readline 4.1-1 on Debian 2.2R6.


root@debian:~# cat .pythonrc
import readline
readline.parse_and_bind("tab: complete")
root@debian:~# python
Python 2.2 (#3, May  7 2002, 05:48:48) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
.bash_history  .profile       batch          extensionTest  todo
.bash_logout   .pythonrc      builds         musketti.txt   
.bashrc        bash.output    debs           temp           
>>> 


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

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



From noreply@sourceforge.net  Fri May 10 21:23:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 May 2002 13:23:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-554663 ] test_fcntl fails on OpenBSD 3.0
Message-ID: <E176Gvh-00012q-00@usw-sf-web4.sourceforge.net>

Bugs item #554663, was opened at 2002-05-10 20:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554663&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Lennart Regebro (regebro)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_fcntl fails on OpenBSD 3.0

Initial Comment:
test_fcntl fails on OpenBSD 3.0 with an error 22.
It's easily fixed by adding 'openbsd3' to the first 
list of platforms, just after 'openbsd2'.

Tadaa!

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

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



From noreply@sourceforge.net  Fri May 10 21:57:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 May 2002 13:57:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-553031 ] StringIO uses wrong length on non-string
Message-ID: <E176HSY-0001Gw-00@usw-sf-web2.sourceforge.net>

Bugs item #553031, was opened at 2002-05-06 21:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553031&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Steve Holden (holdenweb)
Assigned to: Nobody/Anonymous (nobody)
Summary: StringIO uses wrong length on non-string

Initial Comment:
Brian Quinlan points out that StringIO behaves oddly 
when the argument to the creation is not of a string 
type. This is because of a bug in the __init__() 
method. The following patch appears to fix it:

Index: StringIO.py
=======================================================
============
RCS 
file: /cvsroot/python/python/dist/src/Lib/StringIO.py,v
retrieving revision 1.22
diff -r1.22 StringIO.py
45c45
<         self.len = len(buf)
---
>         self.len = len(self.buf)

In Brian's original example he was calling StringIO 
with a list argument, and getting the wrong number of 
characters back.




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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-05-10 20:57

Message:
Logged In: YES 
user_id=31392

I didn't apply this patch, but isn't the line just before
the patched line "self.buf = buf".  If so, I don't see how
the patch can make a difference.

I haven't seen Brian's bug report, but StringIO can't be
called with a list as its argument.  (Well, it can, but it
will save str([]) as self.buf.)

If this is really a bug, can you include an interpreter
session where you show what goes wrong?



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

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



From noreply@sourceforge.net  Fri May 10 22:02:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 May 2002 14:02:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-554676 ] unknown locale de_DE@euro on Suse 8.0 Linux
Message-ID: <E176HX6-0001HA-00@usw-sf-web3.sourceforge.net>

Bugs item #554676, was opened at 2002-05-10 23:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554676&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: vincent wehren (vinweh)
Assigned to: Nobody/Anonymous (nobody)
Summary: unknown locale de_DE@euro on Suse 8.0 Linux

Initial Comment:
Python 2.2 (#1, Mar 26 2002, 15:46:04)   
[GCC 2.95.3 20010315 (SuSE)] on linux2   
 
When calling the locale module's getdefaultlocale() 
method on SuSe 8.0 Linux you get:   
 
>>> locale.getdefaultlocale()   
Traceback (most recent call last):   
  File "<stdin>", line 1, in ?   
  File "/usr/lib/python2.2/locale.py", line 337, in   
getdefaultlocale   
    return _parse_localename(localename)   
  File "/usr/lib/python2.2/locale.py", line 271, in   
_parse_localename   
    raise ValueError, 'unknown locale: %s' %   
localename   
ValueError: unknown locale: de_DE@euro   
  
Evidently, Python2.2's locale module is unaware of 
the "somelang_SOMELANG@euro" nomenclature  
for euro-enabled locales on Linux.  
  
 

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

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



From noreply@sourceforge.net  Fri May 10 22:06:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 May 2002 14:06:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-553031 ] StringIO uses wrong length on non-string
Message-ID: <E176Hav-0001u9-00@usw-sf-web1.sourceforge.net>

Bugs item #553031, was opened at 2002-05-06 17:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553031&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Steve Holden (holdenweb)
Assigned to: Nobody/Anonymous (nobody)
Summary: StringIO uses wrong length on non-string

Initial Comment:
Brian Quinlan points out that StringIO behaves oddly 
when the argument to the creation is not of a string 
type. This is because of a bug in the __init__() 
method. The following patch appears to fix it:

Index: StringIO.py
=======================================================
============
RCS 
file: /cvsroot/python/python/dist/src/Lib/StringIO.py,v
retrieving revision 1.22
diff -r1.22 StringIO.py
45c45
<         self.len = len(buf)
---
>         self.len = len(self.buf)

In Brian's original example he was calling StringIO 
with a list argument, and getting the wrong number of 
characters back.




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

>Comment By: Steve Holden (holdenweb)
Date: 2002-05-10 17:06

Message:
Logged In: YES 
user_id=88157

Sorry: I checked this against 2.2 (where the bug manifested 
itself) rather than CVS :-(

I'll try to be more careful in future.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-05-10 16:57

Message:
Logged In: YES 
user_id=31392

I didn't apply this patch, but isn't the line just before
the patched line "self.buf = buf".  If so, I don't see how
the patch can make a difference.

I haven't seen Brian's bug report, but StringIO can't be
called with a list as its argument.  (Well, it can, but it
will save str([]) as self.buf.)

If this is really a bug, can you include an interpreter
session where you show what goes wrong?



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

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



From noreply@sourceforge.net  Fri May 10 22:07:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 May 2002 14:07:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-551353 ] Python build not Solaris friendly
Message-ID: <E176HbU-0001XG-00@usw-sf-web4.sourceforge.net>

Bugs item #551353, was opened at 2002-05-02 11:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551353&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Phil Eschallier (eschaa00)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python build not Solaris friendly

Initial Comment:
In summary: distutils picks up and uses the proper
values for -I and -L when compiling.  However, Solaris
(and likely other SysV UNIX variants) need -R to the
linker as well.

I posted something to USENET trying to help someone
having _socket problems under Solaris.  The follow-ups
suggested that I create this bug report.

>From USENET:

Folks;

I'm in no way a Python expert ... but I've been playing
with it under
Solaris for the last week, thinking that we should make
the jump from
perl (a different thread).

I wanted to follow-up noting that the build process for
Python under
Solaris is less than perfect.  I've experienced this
same _socket
module not being found and "yes", the build is broken.

The root of the issue is that the distutils used for
compiling
determine the libs needed and add the -I / -L as
needed.  But no -R
options are added.  My problem came from the fact that
I have OpenSSL
deployed under /usr/local/ssl ... and the build process
adds the -L to
find ssl.so and crypt.so ... but the resulting
_socket.so does not
have the runtime path to the OpenSSL libs, the test
load of _socket.so
fails, and it is removed from the build.  The same
holds for TK
support and one or two others.

Under Linux this is a non-issues as ldconfig is available.

My work-around for now is to add all the -L / -R
directives I need to
the CC environment variable before running the initial
'configure'
script (because only hte CC and LDSHARED variables are
passed from
Makefile to setyp.py).

I hope this helps ... and I hope that Python becomes
more Solaris
friendly as it matures.


Cheers.

-- 
Phil Eschallier
Bux Technical Services
70 Irish Meetinghouse Rd
Perkasie, PA  18944
215.249.TECH (215.249.8324)
215.249.8325 (fax)
http://www.BuxTech.Com


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-05-10 21:07

Message:
Logged In: YES 
user_id=31392

The options Martin outlines sound sufficient to me.


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

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

Message:
Logged In: YES 
user_id=21627

When you say that you can accept the Linux build because of
ldconfig(8), then I suggest using crle(1) on Solaris - it
does exactly the same thing.

You have the following options on Solaris:
1) build static PIC libraries of SSL, and use those
2) use crle
3) set LD_RUN_PATH before configuring Python
4) edit Modules/Setup
5) set LD_LIBRARY_PATH at run time

I think these are plenty of options. The Python build is not
Solaris-unfriendly - just if you, as an administrator,
install additional shared libraries on your system, you must
take additional steps when you want to use them.

Outright adding a -R option for every -L option is not the
right solution; if the library to link is static-with-PIC,
then this would be wrong; if crle is used, this would be
also wrong. My recommendation is to abstain from shared
libraries in non-standard directories.

In short, I don't think there is much that can be done about
this. In Python 2.3, the socket and ssl modules are
separate, so you will get socket module even if building the
ssl module fails.

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

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



From noreply@sourceforge.net  Sat May 11 04:37:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 May 2002 20:37:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-554750 ] Circular reference in Index for frame
Message-ID: <E176NhJ-0005X8-00@usw-sf-web4.sourceforge.net>

Bugs item #554750, was opened at 2002-05-11 03:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554750&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Circular reference in Index for frame

Initial Comment:
I hope you don't mind all my anal retentive 
documentation bugs ;-)

In the Python Library Index:
    
http://www.python.org/dev/doc/devel/lib/genindex.html

Go to 'F' and look up 'frame object'.
http://www.python.org/dev/doc/devel/lib/module-
signal.html#l2h-1870

It takes you to the signal documentation here:

    "The handler is called with two arguments: 
    the signal number and the current stack frame
    (None or a frame object; see the reference manual
    for a description of frame objects)."

Besides this circular reference, as far as I can
tell the frame object and it's use in a signal handler
is undocumented.

Frame Objects are mentioned in the Python Reference 
Manual Index, but the named anchor is not correct.
It does link to the correct page, but it brings you
to the top of the page, whereas Frame Objects are not
mentioned until much farther down the page. This is
the link given in the Index:
    
http://www.python.org/dev/doc/devel/ref/types.html#l2h-
59

The details of Frame Objects are still rather fuzzy.

Yours,
Noah


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

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



From noreply@sourceforge.net  Sat May 11 04:38:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 May 2002 20:38:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-554644 ] Minor typo in README
Message-ID: <E176Ni9-00058T-00@usw-sf-web3.sourceforge.net>

Bugs item #554644, was opened at 2002-05-10 15:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554644&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Joonas Paalasmaa (jpaal)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Minor typo in README 

Initial Comment:
There's propably a minor typo in README: ptread_* -> pthread_*.
I uploaded a patch.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-10 23:38

Message:
Logged In: YES 
user_id=3066

Fixed in README revisions 1.146, 1.136.4.5, and 1.122.2.8.

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

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



From noreply@sourceforge.net  Sat May 11 12:51:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 May 2002 04:51:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-551353 ] Python build not Solaris friendly
Message-ID: <E176VPI-00023M-00@usw-sf-web1.sourceforge.net>

Bugs item #551353, was opened at 2002-05-02 06:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551353&group_id=5470

Category: Build
Group: Platform-specific
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Phil Eschallier (eschaa00)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python build not Solaris friendly

Initial Comment:
In summary: distutils picks up and uses the proper
values for -I and -L when compiling.  However, Solaris
(and likely other SysV UNIX variants) need -R to the
linker as well.

I posted something to USENET trying to help someone
having _socket problems under Solaris.  The follow-ups
suggested that I create this bug report.

>From USENET:

Folks;

I'm in no way a Python expert ... but I've been playing
with it under
Solaris for the last week, thinking that we should make
the jump from
perl (a different thread).

I wanted to follow-up noting that the build process for
Python under
Solaris is less than perfect.  I've experienced this
same _socket
module not being found and "yes", the build is broken.

The root of the issue is that the distutils used for
compiling
determine the libs needed and add the -I / -L as
needed.  But no -R
options are added.  My problem came from the fact that
I have OpenSSL
deployed under /usr/local/ssl ... and the build process
adds the -L to
find ssl.so and crypt.so ... but the resulting
_socket.so does not
have the runtime path to the OpenSSL libs, the test
load of _socket.so
fails, and it is removed from the build.  The same
holds for TK
support and one or two others.

Under Linux this is a non-issues as ldconfig is available.

My work-around for now is to add all the -L / -R
directives I need to
the CC environment variable before running the initial
'configure'
script (because only hte CC and LDSHARED variables are
passed from
Makefile to setyp.py).

I hope this helps ... and I hope that Python becomes
more Solaris
friendly as it matures.


Cheers.

-- 
Phil Eschallier
Bux Technical Services
70 Irish Meetinghouse Rd
Perkasie, PA  18944
215.249.TECH (215.249.8324)
215.249.8325 (fax)
http://www.BuxTech.Com


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

>Comment By: Phil Eschallier (eschaa00)
Date: 2002-05-11 06:51

Message:
Logged In: YES 
user_id=532350

jhylton;

Thank you for your time.  While I understand and accept your
closure statement, I was hoping for a bit more universal
solution.  I believe that crle was introduced to Solaris in
2.6; many of my clients still have older versions of the OS
in production and cannot easily upgrade (both political and
technical issues involved) ... so a single style of Solaris
deployment of python would have been nice.

I have a hack designed to get around this.  A number of
USENET readers have followed up with me via E-mail asking
for support, so my original report to you is apparently
affecting more than just my world.

Of course your solution is correct in the purely technical
sense, we'll see how others in the Solaris community react
over time.

Again, thank you.  ... Phil


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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-05-10 16:07

Message:
Logged In: YES 
user_id=31392

The options Martin outlines sound sufficient to me.


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

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

Message:
Logged In: YES 
user_id=21627

When you say that you can accept the Linux build because of
ldconfig(8), then I suggest using crle(1) on Solaris - it
does exactly the same thing.

You have the following options on Solaris:
1) build static PIC libraries of SSL, and use those
2) use crle
3) set LD_RUN_PATH before configuring Python
4) edit Modules/Setup
5) set LD_LIBRARY_PATH at run time

I think these are plenty of options. The Python build is not
Solaris-unfriendly - just if you, as an administrator,
install additional shared libraries on your system, you must
take additional steps when you want to use them.

Outright adding a -R option for every -L option is not the
right solution; if the library to link is static-with-PIC,
then this would be wrong; if crle is used, this would be
also wrong. My recommendation is to abstain from shared
libraries in non-standard directories.

In short, I don't think there is much that can be done about
this. In Python 2.3, the socket and ssl modules are
separate, so you will get socket module even if building the
ssl module fails.

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

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



From noreply@sourceforge.net  Sat May 11 16:35:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 May 2002 08:35:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-554645 ] Strange readline completer behaviour
Message-ID: <E176Ytr-0004DJ-00@usw-sf-web4.sourceforge.net>

Bugs item #554645, was opened at 2002-05-10 19:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554645&group_id=5470

Category: Extension Modules
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Joonas Paalasmaa (jpaal)
>Assigned to: Michael Hudson (mwh)
Summary: Strange readline completer behaviour

Initial Comment:
I have enabled readline completing in my .pythonrc file to which PYTHONSTARTUP
points to. However, when I hit TAB twice in interactive mode, completer
displays the contents of the current directory, not Python's namespace.
I have built Python with readline 4.1-1 on Debian 2.2R6.


root@debian:~# cat .pythonrc
import readline
readline.parse_and_bind("tab: complete")
root@debian:~# python
Python 2.2 (#3, May  7 2002, 05:48:48) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
.bash_history  .profile       batch          extensionTest  todo
.bash_logout   .pythonrc      builds         musketti.txt   
.bashrc        bash.output    debs           temp           
>>> 


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

>Comment By: Michael Hudson (mwh)
Date: 2002-05-11 15:35

Message:
Logged In: YES 
user_id=6656

Chuck an "import rlcompleter" in there too.

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

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



From noreply@sourceforge.net  Sat May 11 17:03:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 May 2002 09:03:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-554912 ] --disable-unicode builds horked
Message-ID: <E176ZLT-0004fE-00@usw-sf-web1.sourceforge.net>

Bugs item #554912, was opened at 2002-05-11 16:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554912&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Hudson (mwh)
Assigned to: Walter Dörwald (doerwalter)
Summary: --disable-unicode builds horked

Initial Comment:
Walter, I'm 99% sure this is your fault:

gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I../Include -DHAVE_CONFIG_H  -o Objects/stringobject.o
../Objects/stringobject.c
../Objects/stringobject.c: In function `do_argstrip':
../Objects/stringobject.c:1461: warning: implicit
declaration of function `PyUnicode_FromObject'
../Objects/stringobject.c:1461: warning: initialization
makes pointer from integer without a cast
../Objects/stringobject.c:1465: warning: implicit
declaration of function `_PyUnicode_XStrip'
../Objects/stringobject.c:1465: `PyUnicodeObject'
undeclared (first use in this function)
../Objects/stringobject.c:1465: (Each undeclared
identifier is reported only once
../Objects/stringobject.c:1465: for each function it
appears in.)
../Objects/stringobject.c:1465: parse error before `)'

Please fix.

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

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



From noreply@sourceforge.net  Sat May 11 17:25:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 May 2002 09:25:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-554916 ] test_unicode fails in wide unicode build
Message-ID: <E176Zh0-0004lK-00@usw-sf-web4.sourceforge.net>

Bugs item #554916, was opened at 2002-05-11 16:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554916&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: M.-A. Lemburg (lemburg)
Summary: test_unicode fails in wide unicode build

Initial Comment:
Assigned somewhat arbitrarily.

It's a roundtrip test, I think.

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

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



From noreply@sourceforge.net  Sun May 12 04:23:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 May 2002 20:23:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-548874 ] Lists do have __getitem__ method
Message-ID: <E176jxb-00033w-00@usw-sf-web4.sourceforge.net>

Bugs item #548874, was opened at 2002-04-25 19:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548874&group_id=5470

Category: None
Group: None
Status: Closed
Resolution: None
Priority: 5
Submitted By: Kelly Gerber (kgerber)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Lists do have __getitem__ method

Initial Comment:
In the Python Reference Manual, Release 2.2.1, section
3.3 Special method names, first paragraph, it says"(The
reverse is not true--if x is a list object,
x.__getitem__(i) is not equivalent to x[i].)"

I do not think this is true any more since Python2.2,
because types now have special methods. They both seem
to produce the same result. Doesn't that make them
equivalent?

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-11 22:23

Message:
Logged In: YES 
user_id=80475

Fixed in Doc/ref/ref3.tex version 1.88.
Bug closed.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-05 10:57

Message:
Logged In: YES 
user_id=80475

Agreed.
Submitted documentation patch: www.python.org/sf/552468

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

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



From noreply@sourceforge.net  Sun May 12 07:36:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 May 2002 23:36:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-555035 ] rfc822.Message.getaddrlist broken
Message-ID: <E176my0-0004GY-00@usw-sf-web3.sourceforge.net>

Bugs item #555035, was opened at 2002-05-12 01:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555035&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry Warsaw (bwarsaw)
Summary: rfc822.Message.getaddrlist broken

Initial Comment:
rfc822.Message.getaddrlist() uses an AddressList 
instance as a helper.  AddressList objects parse 
their inputs during __init__.  Calling 
a.getaddrlist() thus causes the parsing to start 
over, but with the position set past the end of the 
address string.  Instead of calling 
AddressList.getaddrlist() 
rfc822.Message.getaddrlist() should simply access the 
addresslist attribute, e.g., at the end of that 
method it should read:

    alladdrs = ''.join(raw)
    a = AddressList(alladdrs)
    return a.addresslist

Here's a simple example that demonstrates the problem:

    >>> import rfc822
    >>> a = rfc822.AddressList ("skip@pobox.com")
    >>> a.getaddrlist()
    []
    >>> a.addresslist
    [('', 'skip@pobox.com')]

Bugfix candidate?

Skip


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

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



From noreply@sourceforge.net  Sun May 12 07:57:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 11 May 2002 23:57:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-555042 ] zip() may trigger MemoryError
Message-ID: <E176nI5-0004ST-00@usw-sf-web2.sourceforge.net>

Bugs item #555042, was opened at 2002-05-12 01:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555042&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: zip() may trigger MemoryError

Initial Comment:
The recent optimization of zip() trips a MemoryError 
when the only iterable defining len() is xrange
(sys.maxint).

This error may appear in real code because of reliance 
on zip's ability to truncate to the shortest input 
sequence and because xrange(sys.maxint) was an idiom 
for counting elements with-in a zip.  With the 
introduction of enumerate(), the latter is less likely.

The following code works in Py2.2.1 but fails in 2.3a0
(the tree as of 5/12/2002):

Python 2.3a0 (#29, May 12 2002, 02:30:00) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> def g():
...     for i in range(6):
...         yield i
...
>>> zip(g(), xrange(3))
[(0, 0), (1, 1), (2, 2)]
>>> zip(g(), xrange(9))
[(0, 0), (1, 1), (2, 2), (3, 3), (4, 4), (5, 5)]
>>> import sys
>>> zip(g(), xrange(sys.maxint))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError



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

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



From noreply@sourceforge.net  Sun May 12 08:03:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 00:03:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-555042 ] zip() may trigger MemoryError
Message-ID: <E176nOM-0004WZ-00@usw-sf-web2.sourceforge.net>

Bugs item #555042, was opened at 2002-05-12 02:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555042&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Tim Peters (tim_one)
Summary: zip() may trigger MemoryError

Initial Comment:
The recent optimization of zip() trips a MemoryError 
when the only iterable defining len() is xrange
(sys.maxint).

This error may appear in real code because of reliance 
on zip's ability to truncate to the shortest input 
sequence and because xrange(sys.maxint) was an idiom 
for counting elements with-in a zip.  With the 
introduction of enumerate(), the latter is less likely.

The following code works in Py2.2.1 but fails in 2.3a0
(the tree as of 5/12/2002):

Python 2.3a0 (#29, May 12 2002, 02:30:00) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> def g():
...     for i in range(6):
...         yield i
...
>>> zip(g(), xrange(3))
[(0, 0), (1, 1), (2, 2)]
>>> zip(g(), xrange(9))
[(0, 0), (1, 1), (2, 2), (3, 3), (4, 4), (5, 5)]
>>> import sys
>>> zip(g(), xrange(sys.maxint))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError



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

>Comment By: Tim Peters (tim_one)
Date: 2002-05-12 03:03

Message:
Logged In: YES 
user_id=31435

Assigned to me.

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

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



From noreply@sourceforge.net  Sun May 12 08:20:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 00:20:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-555042 ] zip() may trigger MemoryError
Message-ID: <E176neu-0004fN-00@usw-sf-web3.sourceforge.net>

Bugs item #555042, was opened at 2002-05-12 02:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555042&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Tim Peters (tim_one)
Summary: zip() may trigger MemoryError

Initial Comment:
The recent optimization of zip() trips a MemoryError 
when the only iterable defining len() is xrange
(sys.maxint).

This error may appear in real code because of reliance 
on zip's ability to truncate to the shortest input 
sequence and because xrange(sys.maxint) was an idiom 
for counting elements with-in a zip.  With the 
introduction of enumerate(), the latter is less likely.

The following code works in Py2.2.1 but fails in 2.3a0
(the tree as of 5/12/2002):

Python 2.3a0 (#29, May 12 2002, 02:30:00) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> def g():
...     for i in range(6):
...         yield i
...
>>> zip(g(), xrange(3))
[(0, 0), (1, 1), (2, 2)]
>>> zip(g(), xrange(9))
[(0, 0), (1, 1), (2, 2), (3, 3), (4, 4), (5, 5)]
>>> import sys
>>> zip(g(), xrange(sys.maxint))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError



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

>Comment By: Tim Peters (tim_one)
Date: 2002-05-12 03:20

Message:
Logged In: YES 
user_id=31435

Fixed, in

Lib/test/test_b2.py; new revision: 1.34
Python/bltinmodule.c; new revision: 2.255

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

Comment By: Tim Peters (tim_one)
Date: 2002-05-12 03:03

Message:
Logged In: YES 
user_id=31435

Assigned to me.

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

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



From noreply@sourceforge.net  Sun May 12 08:26:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 00:26:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-551673 ] Poor error message for float()
Message-ID: <E176nk2-0005mc-00@usw-sf-web1.sourceforge.net>

Bugs item #551673, was opened at 2002-05-02 19:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551673&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward C. Jones (edcjones)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Poor error message for float()

Initial Comment:
This line of Python (2.2):

    x = float([0])

gives the error:

    TypeError: float() needs a string argument

But since "float(0)" is OK, a better error message
might be:

    TypeError: the argument of float() must be a string
or a number

I use RedHat 7.1 Linux on a PC.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 02:26

Message:
Logged In: YES 
user_id=80475

This has been fixed for Python 2.3 which now says:
TypeError: float() argument must be a string or a number.

Will look at backporting to a maintenance release of Python 
2.2.


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

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



From noreply@sourceforge.net  Sun May 12 08:33:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 00:33:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-553262 ] [RefMan] Special status of "as"
Message-ID: <E176nrP-0004oJ-00@usw-sf-web2.sourceforge.net>

Bugs item #553262, was opened at 2002-05-07 08:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553262&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: [RefMan] Special status of "as"

Initial Comment:
The special status of "as" in import statements needs
to be acknowledged in the list of keywords (RefMan 2.3.1).

(Based on note sent to python-docs.)

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 02:33

Message:
Logged In: YES 
user_id=80475

Several important words like None are not listed as 
keywords.  In this case, there is no need because assigning 
to 'as' does not ambiguate the syntax:

>>> import sys as sass
>>> dir()
['__builtins__', '__doc__', '__name__', 'sass']
>>> as = 12
>>> import os as oz
>>> dir()
['__builtins__', '__doc__', '__name__', 'as', 'oz', 'sass']

Thanks for raising the issue.  I'm going to close this one 
because I think it's invalid.  If someone disagrees, feel 
free to resurrect it.

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

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



From noreply@sourceforge.net  Sun May 12 08:42:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 00:42:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-548693 ] Missing or wrong index entries
Message-ID: <E176o0M-0004sT-00@usw-sf-web3.sourceforge.net>

Bugs item #548693, was opened at 2002-04-25 11:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548693&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Missing or wrong index entries

Initial Comment:
As repoted by Cliff Wells in private email to me:

The dictionary's 'setdefault' method is not if the
library index.

'has_key' is listed in the library index as Queue
method, but the entry refers to "Hash, Btree, and
Record Objects" of bsddb.


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

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



From noreply@sourceforge.net  Sun May 12 08:45:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 00:45:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-553262 ] [RefMan] Special status of "as"
Message-ID: <E176o2X-0004vO-00@usw-sf-web2.sourceforge.net>

Bugs item #553262, was opened at 2002-05-07 09:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553262&group_id=5470

Category: Documentation
Group: None
>Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: [RefMan] Special status of "as"

Initial Comment:
The special status of "as" in import statements needs
to be acknowledged in the list of keywords (RefMan 2.3.1).

(Based on note sent to python-docs.)

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

>Comment By: Tim Peters (tim_one)
Date: 2002-05-12 03:45

Message:
Logged In: YES 
user_id=31435

Reopened.  When an active developer opens a bug and assigns 
it to themself (Fred opened this and assigned it to 
himself), they have a reason that shouldn't be second-
guessed without discussion (in this case, "as" is not a 
builtin name, and it is special in one context -- Fred 
wants a reminder here to change the docs accordingly).

Unfortunately, once the Resolution field on an SF report is 
set to anything other than "None", it can't be changed back 
to None again.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 03:33

Message:
Logged In: YES 
user_id=80475

Several important words like None are not listed as 
keywords.  In this case, there is no need because assigning 
to 'as' does not ambiguate the syntax:

>>> import sys as sass
>>> dir()
['__builtins__', '__doc__', '__name__', 'sass']
>>> as = 12
>>> import os as oz
>>> dir()
['__builtins__', '__doc__', '__name__', 'as', 'oz', 'sass']

Thanks for raising the issue.  I'm going to close this one 
because I think it's invalid.  If someone disagrees, feel 
free to resurrect it.

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

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



From noreply@sourceforge.net  Sun May 12 13:12:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 05:12:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-457114 ] Incorporate timeoutsocket.py into core
Message-ID: <E176sDV-000297-00@usw-sf-web1.sourceforge.net>

Bugs item #457114, was opened at 2001-08-31 01:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorporate timeoutsocket.py into core

Initial Comment:
I was responding to a question on c.l.py earlier about
urllib hanging and was reminded of Tim O'Malley's
timeoutsocket.py.  It's a shim above socket that allows
you to set timeouts on any TCP connections.  Back in
January, Jeff Bauer suggested in c.l.py that it be
included in the core.  I agree that it provides useful
extra functionality beyond the current socket
implementation and would like it to be considered for
addition to the standard distribution.  Here's a
pointer:

    http://www.timo-tasi.org/python/timeoutsocket.py

Here's how you use it:

    import timeoutsocket
    import httplib
    timeoutsocket.setDefaultSocketTimeout(20)
    # at this point any sockets created
    # will have a 20-second timeout
    h = httplib.HTTP("www.python.org")

Pretty simple, huh?

Skip


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

Comment By: Michael Gilfix (mgilfix)
Date: 2002-05-12 08:12

Message:
Logged In: YES 
user_id=116038

A patch for this now exists in the SF tracker: #555085.

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

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-22 23:56

Message:
Logged In: YES 
user_id=116038

For the record, I have a patch. I'm coordinating with
Bernard Yue for some preliminary testing and it'll added
into the patch tracker shortly.

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

Comment By: Skip Montanaro (montanaro)
Date: 2002-04-17 11:32

Message:
Logged In: YES 
user_id=44345

Check the python-dev mailing list archive for the past few
days.  There is an active thread about this topic.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-17 08:14

Message:
Logged In: YES 
user_id=6380

Bernard Yue is considering to tackle this. See the thread in
python-dev starting at
http://mail.python.org/pipermail/python-dev/2002-April/023278.html
Maybe you two can work on this together?


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

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-17 01:22

Message:
Logged In: YES 
user_id=116038

I'd be interested in integrating the two modules if no one
has tackled this yet. Seems like it would make a cool
feature.

I'm a little unclear on where you think the best integration
(and I'm a little new to the interpreter source :) ) point
would be - in the python module interface socket.py or the
lower level c interface socketmodule.c.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-09-05 16:46

Message:
Logged In: YES 
user_id=44345

While the offer is tempting, I almost certainly don't
understand the various bits associated with sockets and
don't have the time to learn them, so I'm unassigning.
Hopefully someone else will pick it up for 2.3...

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 14:26

Message:
Logged In: YES 
user_id=6380

Skip, want to work on this? If not, please unassign it.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-31 09:10

Message:
Logged In: YES 
user_id=6380

I like this idea, but don't think this exact implementation
belongs in the standard library. The hacks deployed to
"install" the special effect are a bit fragile, e.g.
consider "import socket as foo"; and they shouldn't be
necessary.

When integrated into the standard library, it should
probably become a standard feature of the socket object.
Note that on Windows, socket.socket is already a shim on top
of _socket.socket, so that would be a convenient starting
point.

Patch anyone?

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

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



From noreply@sourceforge.net  Sun May 12 18:24:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 10:24:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-551673 ] Poor error message for float()
Message-ID: <E176x4i-0004jQ-00@usw-sf-web1.sourceforge.net>

Bugs item #551673, was opened at 2002-05-02 19:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551673&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Edward C. Jones (edcjones)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Poor error message for float()

Initial Comment:
This line of Python (2.2):

    x = float([0])

gives the error:

    TypeError: float() needs a string argument

But since "float(0)" is OK, a better error message
might be:

    TypeError: the argument of float() must be a string
or a number

I use RedHat 7.1 Linux on a PC.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 12:23

Message:
Logged In: YES 
user_id=80475

Backported fix from Py2.3 to the Python2.2 maintenance 
release.  Committed as floatobject.c 2.110.6.2.
Closing bug.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 02:26

Message:
Logged In: YES 
user_id=80475

This has been fixed for Python 2.3 which now says:
TypeError: float() argument must be a string or a number.

Will look at backporting to a maintenance release of Python 
2.2.


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

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



From noreply@sourceforge.net  Mon May 13 02:34:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 18:34:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-548693 ] Missing or wrong index entries
Message-ID: <E1774j9-0000Cw-00@usw-sf-web2.sourceforge.net>

Bugs item #548693, was opened at 2002-04-25 11:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548693&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Missing or wrong index entries

Initial Comment:
As repoted by Cliff Wells in private email to me:

The dictionary's 'setdefault' method is not if the
library index.

'has_key' is listed in the library index as Queue
method, but the entry refers to "Hash, Btree, and
Record Objects" of bsddb.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 20:34

Message:
Logged In: YES 
user_id=80475

Added patch to index missing methods.
Note, has_key was already fixed by Py2.2.

Fred, is this patch okay to commit?

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

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



From noreply@sourceforge.net  Mon May 13 02:39:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 18:39:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-548693 ] Missing or wrong index entries
Message-ID: <E1774ns-0000Fu-00@usw-sf-web2.sourceforge.net>

Bugs item #548693, was opened at 2002-04-25 11:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548693&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Missing or wrong index entries

Initial Comment:
As repoted by Cliff Wells in private email to me:

The dictionary's 'setdefault' method is not if the
library index.

'has_key' is listed in the library index as Queue
method, but the entry refers to "Hash, Btree, and
Record Objects" of bsddb.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 20:39

Message:
Logged In: YES 
user_id=80475

Okay to check-in?
Also, okay to back-patch to release22-maint (without the pop
() method)?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 20:34

Message:
Logged In: YES 
user_id=80475

Added patch to index missing methods.
Note, has_key was already fixed by Py2.2.

Fred, is this patch okay to commit?

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

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



From noreply@sourceforge.net  Mon May 13 05:03:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 21:03:19 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-426539 ] Math-module lacks some docs and funcs
Message-ID: <E17773P-0002Lc-00@usw-sf-web4.sourceforge.net>

Feature Requests item #426539, was opened at 2001-05-22 23:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=426539&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rikard Bosnjakovic (bosna)
Assigned to: Nobody/Anonymous (nobody)
Summary: Math-module lacks some docs and funcs

Initial Comment:
>>> import math
>>> print math.cos.__doc__
cos(x)

Return the cosine of x.


1. That doc-string is not very sufficient, since it
does not tell whether x should be in radians or
degrees. Same goes with sin, asin, acos and the rest of
the degree-functions.

2. ceil() and floor() could have some more information
of what the functions does. Not all users have taken
math-courses and know about them.

3. Add a degrees(x) and radians(x) that converts "x" to
degrees (from a radian argument) and to radians (from a
degree argument) respectively, it's pretty useful.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 23:03

Message:
Logged In: YES 
user_id=80475

Comment #3 resolved.

Committed as mathmodule 2.67, 
libmath.tex 1.26 and test_math.py 1.14.

Comments #1 and #2 already solved.

Closing patch and feature request.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-05 10:55

Message:
Logged In: YES 
user_id=80475

As of version 2.2, comments #1 and #2 were resolved.
Submitted patch for #3:  www.python.org/sf/552452


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

Comment By: Tim Peters (tim_one)
Date: 2001-06-04 13:38

Message:
Logged In: YES 
user_id=31435

Chagned to Feature Request, Interpreter Core, and added two 
entries to PEP 42 (one for fatter docs, another for the new 
functions).

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

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



From noreply@sourceforge.net  Mon May 13 07:29:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 23:29:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E1779Kh-0003FD-00@usw-sf-web2.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 08:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 01:29

Message:
Logged In: YES 
user_id=80475

Fred, here's a doc patch.
Okay to commit and close this bug?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 07:37

Message:
Logged In: YES 
user_id=6380

Note: complex % is also being deprecated.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:42

Message:
Logged In: YES 
user_id=6380

Fred, can you fix the docs?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:36

Message:
Logged In: YES 
user_id=6380

OK, I'll add the deprecation warning.

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

Comment By: Tim Peters (tim_one)
Date: 2002-04-14 20:23

Message:
Logged In: YES 
user_id=31435

Heh.  divmod(c1, c2)[0] for complexes returns
  floor((c1/c2).real)
according to the Reference Manual (5.6 Binary arithmetic 
operations), and it looks like the code implements that 
just so.  The Library manual's "Builtin Functions" section 
only mentions ints, longs and floats, while the same 
manual's "2.2.4 Numeric Types" claims, in a footnote, 
that "Builtin Functions" told the full truth about divmod.

The primary lesson I take from this is that a .chm file is 
a truly wonderful way to search the docs <wink>.

I don't think divmod is useful for complexes, and would be 
happy to see it go away.  But I guess that means taking the 
full-blown deprecation path.

I note that the original complexobject.c didn't implement 
divmod.  The current divmod appears to derive from a patch 
contributed by Tim Hochberg, in rev 2.10 in 1996.  You 
(Guido) added a question mark to the checkin comment, so I 
figure it never made much sense to you either.

I agree floor divsion and divmod(...)[0] should do the same 
thing, whatever that is.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 19:44

Message:
Logged In: YES 
user_id=6380

Hm. I believe that if divmod() returns something, // should
return the same thing (well, divmod()[0]). But what on earth
does divmod() do on two complex numbers??? Does it make
sense to have divmod() on complex at all? Assigned to Tim
for a ruling.

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

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 18:24

Message:
Logged In: YES 
user_id=112690

As suggested by Tim I'll upload here the patch and the test
for this bug.
The patch clears nb_true_divide entry and deletes the
complex_int_div function.


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

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



From noreply@sourceforge.net  Mon May 13 07:33:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 23:33:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-553262 ] [RefMan] Special status of "as"
Message-ID: <E1779OR-00033Z-00@usw-sf-web3.sourceforge.net>

Bugs item #553262, was opened at 2002-05-07 08:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553262&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: [RefMan] Special status of "as"

Initial Comment:
The special status of "as" in import statements needs
to be acknowledged in the list of keywords (RefMan 2.3.1).

(Based on note sent to python-docs.)

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 01:33

Message:
Logged In: YES 
user_id=80475

My mistake :(

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

Comment By: Tim Peters (tim_one)
Date: 2002-05-12 02:45

Message:
Logged In: YES 
user_id=31435

Reopened.  When an active developer opens a bug and assigns 
it to themself (Fred opened this and assigned it to 
himself), they have a reason that shouldn't be second-
guessed without discussion (in this case, "as" is not a 
builtin name, and it is special in one context -- Fred 
wants a reminder here to change the docs accordingly).

Unfortunately, once the Resolution field on an SF report is 
set to anything other than "None", it can't be changed back 
to None again.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 02:33

Message:
Logged In: YES 
user_id=80475

Several important words like None are not listed as 
keywords.  In this case, there is no need because assigning 
to 'as' does not ambiguate the syntax:

>>> import sys as sass
>>> dir()
['__builtins__', '__doc__', '__name__', 'sass']
>>> as = 12
>>> import os as oz
>>> dir()
['__builtins__', '__doc__', '__name__', 'as', 'oz', 'sass']

Thanks for raising the issue.  I'm going to close this one 
because I think it's invalid.  If someone disagrees, feel 
free to resurrect it.

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

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



From noreply@sourceforge.net  Mon May 13 07:39:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 12 May 2002 23:39:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-553262 ] [RefMan] Special status of "as"
Message-ID: <E1779UO-0003M4-00@usw-sf-web2.sourceforge.net>

Bugs item #553262, was opened at 2002-05-07 09:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553262&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: [RefMan] Special status of "as"

Initial Comment:
The special status of "as" in import statements needs
to be acknowledged in the list of keywords (RefMan 2.3.1).

(Based on note sent to python-docs.)

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

>Comment By: Tim Peters (tim_one)
Date: 2002-05-13 02:39

Message:
Logged In: YES 
user_id=31435

That's OK. *I* still love you!  Not sure about Fred <wink>.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 02:33

Message:
Logged In: YES 
user_id=80475

My mistake :(

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

Comment By: Tim Peters (tim_one)
Date: 2002-05-12 03:45

Message:
Logged In: YES 
user_id=31435

Reopened.  When an active developer opens a bug and assigns 
it to themself (Fred opened this and assigned it to 
himself), they have a reason that shouldn't be second-
guessed without discussion (in this case, "as" is not a 
builtin name, and it is special in one context -- Fred 
wants a reminder here to change the docs accordingly).

Unfortunately, once the Resolution field on an SF report is 
set to anything other than "None", it can't be changed back 
to None again.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 03:33

Message:
Logged In: YES 
user_id=80475

Several important words like None are not listed as 
keywords.  In this case, there is no need because assigning 
to 'as' does not ambiguate the syntax:

>>> import sys as sass
>>> dir()
['__builtins__', '__doc__', '__name__', 'sass']
>>> as = 12
>>> import os as oz
>>> dir()
['__builtins__', '__doc__', '__name__', 'as', 'oz', 'sass']

Thanks for raising the issue.  I'm going to close this one 
because I think it's invalid.  If someone disagrees, feel 
free to resurrect it.

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

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



From noreply@sourceforge.net  Mon May 13 10:18:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 02:18:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-554912 ] --disable-unicode builds horked
Message-ID: <E177Byl-0005iI-00@usw-sf-web4.sourceforge.net>

Bugs item #554912, was opened at 2002-05-11 18:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554912&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Hudson (mwh)
Assigned to: Walter Dörwald (doerwalter)
Summary: --disable-unicode builds horked

Initial Comment:
Walter, I'm 99% sure this is your fault:

gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I../Include -DHAVE_CONFIG_H  -o Objects/stringobject.o
../Objects/stringobject.c
../Objects/stringobject.c: In function `do_argstrip':
../Objects/stringobject.c:1461: warning: implicit
declaration of function `PyUnicode_FromObject'
../Objects/stringobject.c:1461: warning: initialization
makes pointer from integer without a cast
../Objects/stringobject.c:1465: warning: implicit
declaration of function `_PyUnicode_XStrip'
../Objects/stringobject.c:1465: `PyUnicodeObject'
undeclared (first use in this function)
../Objects/stringobject.c:1465: (Each undeclared
identifier is reported only once
../Objects/stringobject.c:1465: for each function it
appears in.)
../Objects/stringobject.c:1465: parse error before `)'

Please fix.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 11:18

Message:
Logged In: YES 
user_id=89016

You're 99% correct!

Fixed in stringobject 2.162 and 2.147.6.5 (for the
release22-maint branch).

The docstring for strip, lstrip and rstrip still
mention unicode. Should this be fixed too?


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

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



From noreply@sourceforge.net  Mon May 13 10:21:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 02:21:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E177C1I-00068r-00@usw-sf-web1.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 18:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: M.-A. Lemburg (lemburg)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

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



From noreply@sourceforge.net  Mon May 13 10:37:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 02:37:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-554912 ] --disable-unicode builds horked
Message-ID: <E177CGv-0005Le-00@usw-sf-web2.sourceforge.net>

Bugs item #554912, was opened at 2002-05-11 16:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554912&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Michael Hudson (mwh)
Assigned to: Walter Dörwald (doerwalter)
Summary: --disable-unicode builds horked

Initial Comment:
Walter, I'm 99% sure this is your fault:

gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I../Include -DHAVE_CONFIG_H  -o Objects/stringobject.o
../Objects/stringobject.c
../Objects/stringobject.c: In function `do_argstrip':
../Objects/stringobject.c:1461: warning: implicit
declaration of function `PyUnicode_FromObject'
../Objects/stringobject.c:1461: warning: initialization
makes pointer from integer without a cast
../Objects/stringobject.c:1465: warning: implicit
declaration of function `_PyUnicode_XStrip'
../Objects/stringobject.c:1465: `PyUnicodeObject'
undeclared (first use in this function)
../Objects/stringobject.c:1465: (Each undeclared
identifier is reported only once
../Objects/stringobject.c:1465: for each function it
appears in.)
../Objects/stringobject.c:1465: parse error before `)'

Please fix.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-05-13 09:37

Message:
Logged In: YES 
user_id=6656

My cronjob thanks you :)

I wouldn't bother fixing the docstrings, myself, so I'll
close this.

Now to get StringIO working... (currently testing patch).

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 09:18

Message:
Logged In: YES 
user_id=89016

You're 99% correct!

Fixed in stringobject 2.162 and 2.147.6.5 (for the
release22-maint branch).

The docstring for strip, lstrip and rstrip still
mention unicode. Should this be fixed too?


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

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



From noreply@sourceforge.net  Mon May 13 13:20:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 05:20:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-555404 ] bug in utils.py (not allow "" pathname)
Message-ID: <E177Eo6-0008Cf-00@usw-sf-web1.sourceforge.net>

Bugs item #555404, was opened at 2002-05-13 12:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555404&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Evgeny Cherkashin (eugeneai)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in utils.py (not allow "" pathname)

Initial Comment:
According to documentation : "If You want to place a
data file in Python root directory You should use "" as
a path name". But in this case exception raised due to
check pathname[0]=='/'

Just add a line marked by "+".

in convert_path method

     if os.sep == '/':
         return pathname
+    if pathname == '': return
     if pathname[0] == '/':
         raise ValueError, "path '%s' cannot be
absolute" % pathname
     if pathname[-1] == '/':
         raise ValueError, "path '%s' cannot end with
'/'" % pathname


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

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



From noreply@sourceforge.net  Mon May 13 14:38:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 06:38:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-554916 ] test_unicode fails in wide unicode build
Message-ID: <E177G2D-0000GD-00@usw-sf-web4.sourceforge.net>

Bugs item #554916, was opened at 2002-05-11 18:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554916&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: M.-A. Lemburg (lemburg)
Summary: test_unicode fails in wide unicode build

Initial Comment:
Assigned somewhat arbitrarily.

It's a roundtrip test, I think.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 15:38

Message:
Logged In: YES 
user_id=89016

The minimal failing testcase is:

>>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") ==
u"\udb00\udc00"
False

which is strange, because they *seem* to be the same:

u"\udb00\udc00"
u'\U000d0000'
>>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8")      
            
u'\U000d0000'


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

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



From noreply@sourceforge.net  Mon May 13 14:58:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 06:58:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-554916 ] test_unicode fails in wide unicode build
Message-ID: <E177GLF-0000uX-00@usw-sf-web1.sourceforge.net>

Bugs item #554916, was opened at 2002-05-11 16:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554916&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: M.-A. Lemburg (lemburg)
Summary: test_unicode fails in wide unicode build

Initial Comment:
Assigned somewhat arbitrarily.

It's a roundtrip test, I think.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-05-13 13:58

Message:
Logged In: YES 
user_id=6656

>>> a = u"\udb00\udc00"
[20811 refs]
>>> b = unicode(a.encode("utf-8"), "utf-8")
[21061 refs]
>>> a, b 
(u'\U000d0000', u'\U000d0000')
[21063 refs]
>>> len(a), len(b)
(2, 1)
[21063 refs]

Erm...?

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 13:38

Message:
Logged In: YES 
user_id=89016

The minimal failing testcase is:

>>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") ==
u"\udb00\udc00"
False

which is strange, because they *seem* to be the same:

u"\udb00\udc00"
u'\U000d0000'
>>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8")      
            
u'\U000d0000'


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

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



From noreply@sourceforge.net  Mon May 13 15:47:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 07:47:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E177H6R-0000Vm-00@usw-sf-web2.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
>Group: Platform-specific
Status: Open
Resolution: None
>Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 10:47

Message:
Logged In: YES 
user_id=6380

I see no reason why this should be priority 8, since all
evidence points towards the platform as the culprit. (IRIX
is notorious, though this is a new one.)

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

Comment By: Michael Hudson (mwh)
Date: 2002-05-10 04:41

Message:
Logged In: YES 
user_id=6656

Is there some way to tell which executable dumped the core
file?  It'd be "size core" on linux, dunno what on IRIX.

If it's /bin/sh, I'm not really sure what we can do...

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-09 14:18

Message:
Logged In: YES 
user_id=32232

I tried running with --disable-ipv6 and got exactly the same
crash. I edited 'configure' and added extra instructions to
have some idea what is happening. I modified fragment at
line 4361 from:
============================================
if test "${enable_ipv6+set}" = set; then
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else

============================================

to 

============================================
if test "${enable_ipv6+set}" = set; then
  echo "l. 4362"
else
  echo "l. 4364"
fi
if test "${enable_ipv6+set}" = set; then
  echo "l. 4367"
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else
  echo "l. 4383"
===========================================

The interesting part is that "l.4362" or "l.4364" are
printed depending on option "--disable-ipv6" being used, as
expected. However, the program crashes befere either
"l.4367" or "l.4383" is printed. For instance if I run
"./configure --disable-ipv6" the last lines of output are:

checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... l. 4362
Segmentation fault (core dumped)

The modified config is attached. Maybe there is some problem
with interpreting the 'configure' itself?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-08 04:45

Message:
Logged In: YES 
user_id=45365

The test for IPv6 support on your machine actually tries to run a program that uses IPv6. So, could it be that you have IPv6 support partially installed? For instance, you have the headers (does AF_INET6 occur anywhere in <sys/socket.h> or any flie it includes?) but not the corresponding C library.

This guess is easy to check: try a "./configure --disable-ipv6". If that works fine then the oabove is your problem, probably, and you also have a  workaround:-)

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-07 23:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 16:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Mon May 13 15:48:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 07:48:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-553512 ] cPickle dies on short reads
Message-ID: <E177H7X-0000WL-00@usw-sf-web2.sourceforge.net>

Bugs item #553512, was opened at 2002-05-07 19:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553512&group_id=5470

Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle dies on short reads

Initial Comment:
I discovered that cPickle can report various failures
when reading from a file object created by a socket's
makefile() method, probably due to not dealing
correctly with short reads. I've seen this in 2.1.3 so
I believe it must be widespread.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 10:48

Message:
Logged In: YES 
user_id=6380

I haven't been able to reproduce this, and I changed the
code that broke so as to avoid the issue, so I'm closing
this now, for better or for worse.

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

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



From noreply@sourceforge.net  Mon May 13 15:53:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 07:53:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-553736 ] thread_pthread.h on FreeBSD
Message-ID: <E177HCP-0000N8-00@usw-sf-web3.sourceforge.net>

Bugs item #553736, was opened at 2002-05-08 11:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553736&group_id=5470

Category: Threads
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Sawyers (zc_andrew)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread_pthread.h on FreeBSD

Initial Comment:
The pthread setstacksize of 64K is too small for 
FreeBSD in some cases (i.e. specifically when running 
Zope/CMF).  The attached diff has worked on 3+ 
different production sites; though the setting of the 
stacksize to 128K was WAG.  It might be possible to 
still overflow the stacksize, though in all the sites 
using this change are no longer having problems.
I've spoken with Fred about this on a few occassions...
Thanks,
Andrew

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 10:53

Message:
Logged In: YES 
user_id=6380

It looks like a similar change has already been applied to
2.2 and beyond. Does that work for you? Do you think it
would be useful to backport this change to the Python 2.1.x
series?

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

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



From noreply@sourceforge.net  Mon May 13 15:56:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 07:56:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-554073 ] bug in telnetlib- 'opt' instead of 'c'
Message-ID: <E177HFc-0000PY-00@usw-sf-web3.sourceforge.net>

Bugs item #554073, was opened at 2002-05-09 07:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554073&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: Christos Georgiou (tzot)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in telnetlib- 'opt' instead of 'c'

Initial Comment:
Line 424 of telnetlib.py is:
  self.msg('IAC %d not recognized' % ord(opt))
but this is wrong, because the variable that should be 
used is 'c', as such:
  self.msg('IAC %d not recognized' % ord(c))

Reference: http://groups.google.com/groups?selm=a4me60%
24brk%240%40216.39.172.122

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 10:56

Message:
Logged In: YES 
user_id=6380

Thanks! Fixed in CVS.

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

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



From noreply@sourceforge.net  Mon May 13 15:06:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 07:06:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-554916 ] test_unicode fails in wide unicode build
Message-ID: <E177GTN-00010p-00@usw-sf-web1.sourceforge.net>

Bugs item #554916, was opened at 2002-05-11 16:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554916&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: M.-A. Lemburg (lemburg)
Summary: test_unicode fails in wide unicode build

Initial Comment:
Assigned somewhat arbitrarily.

It's a roundtrip test, I think.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-05-13 14:06

Message:
Logged In: YES 
user_id=6656

Even better: 

$ ./python 
Adding parser accelerators ...
Done.
Python 2.2.1 (#1, May 13 2002, 15:02:01) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") ==
u"\udb00\udc00"
0
[18762 refs]

but the test passes.  And there was me thinking that it
wasn't a problem on the release22-maint branch.

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

Comment By: Michael Hudson (mwh)
Date: 2002-05-13 13:58

Message:
Logged In: YES 
user_id=6656

>>> a = u"\udb00\udc00"
[20811 refs]
>>> b = unicode(a.encode("utf-8"), "utf-8")
[21061 refs]
>>> a, b 
(u'\U000d0000', u'\U000d0000')
[21063 refs]
>>> len(a), len(b)
(2, 1)
[21063 refs]

Erm...?

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

Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 13:38

Message:
Logged In: YES 
user_id=89016

The minimal failing testcase is:

>>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") ==
u"\udb00\udc00"
False

which is strange, because they *seem* to be the same:

u"\udb00\udc00"
u'\U000d0000'
>>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8")      
            
u'\U000d0000'


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

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



From noreply@sourceforge.net  Mon May 13 16:30:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 08:30:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E177HmL-0001x9-00@usw-sf-web1.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 22:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-05-13 17:30

Message:
Logged In: YES 
user_id=43607

The error message indicates that it is the shell that runs
the configure script that crashes.  Otherwise the script
would continue (and possibly give other error messages).
Try "file core", this should tell you which program produced
the core (I expect configure).  If this is indeed the case,
the bug is not in Python but in the shell.
Do you have a non-standard /bin/sh?
Which version of IRIX 6.5 are you running (try "versions
eoe.sw.base")?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 16:47

Message:
Logged In: YES 
user_id=6380

I see no reason why this should be priority 8, since all
evidence points towards the platform as the culprit. (IRIX
is notorious, though this is a new one.)

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

Comment By: Michael Hudson (mwh)
Date: 2002-05-10 10:41

Message:
Logged In: YES 
user_id=6656

Is there some way to tell which executable dumped the core
file?  It'd be "size core" on linux, dunno what on IRIX.

If it's /bin/sh, I'm not really sure what we can do...

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-09 20:18

Message:
Logged In: YES 
user_id=32232

I tried running with --disable-ipv6 and got exactly the same
crash. I edited 'configure' and added extra instructions to
have some idea what is happening. I modified fragment at
line 4361 from:
============================================
if test "${enable_ipv6+set}" = set; then
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else

============================================

to 

============================================
if test "${enable_ipv6+set}" = set; then
  echo "l. 4362"
else
  echo "l. 4364"
fi
if test "${enable_ipv6+set}" = set; then
  echo "l. 4367"
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else
  echo "l. 4383"
===========================================

The interesting part is that "l.4362" or "l.4364" are
printed depending on option "--disable-ipv6" being used, as
expected. However, the program crashes befere either
"l.4367" or "l.4383" is printed. For instance if I run
"./configure --disable-ipv6" the last lines of output are:

checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... l. 4362
Segmentation fault (core dumped)

The modified config is attached. Maybe there is some problem
with interpreting the 'configure' itself?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-08 10:45

Message:
Logged In: YES 
user_id=45365

The test for IPv6 support on your machine actually tries to run a program that uses IPv6. So, could it be that you have IPv6 support partially installed? For instance, you have the headers (does AF_INET6 occur anywhere in <sys/socket.h> or any flie it includes?) but not the corresponding C library.

This guess is easy to check: try a "./configure --disable-ipv6". If that works fine then the oabove is your problem, probably, and you also have a  workaround:-)

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-08 05:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 22:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Mon May 13 15:58:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 07:58:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-554663 ] test_fcntl fails on OpenBSD 3.0
Message-ID: <E177HHR-0001Bf-00@usw-sf-web4.sourceforge.net>

Bugs item #554663, was opened at 2002-05-10 16:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=554663&group_id=5470

Category: Installation
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Lennart Regebro (regebro)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_fcntl fails on OpenBSD 3.0

Initial Comment:
test_fcntl fails on OpenBSD 3.0 with an error 22.
It's easily fixed by adding 'openbsd3' to the first 
list of platforms, just after 'openbsd2'.

Tadaa!

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 10:58

Message:
Logged In: YES 
user_id=6380

OK, fixed in CVS as you proposed.

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

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



From noreply@sourceforge.net  Mon May 13 17:40:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 09:40:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E177IsW-0002Pe-00@usw-sf-web4.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 12:40

Message:
Logged In: YES 
user_id=32232

"file core" outputs:
core:           IRIX N32 core dump of 'configure'

"versions eoe.sw.base" outputs
I  eoe                  03/05/2002  IRIX Execution
Environment, 6.5.15f
I  eoe.sw               03/05/2002  IRIX Execution
Environment Software
I  eoe.sw.base          03/05/2002  IRIX Base Execution
Environment

I am using /bin/sh that comes with the system (I am not the
system administrator). Looks to me that this is a problem
with /bin/sh. I tried to remove from configure whole block
that tests ipv6 but this just crushes configure same way on
the next test.Tried to put "echo" commands in side and
outside the in line 4360 (where the script crushes). Last
echo prints just before if, never inside, or after. As is
/bin/sh crashes while parsing the script(?).

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-05-13 11:30

Message:
Logged In: YES 
user_id=43607

The error message indicates that it is the shell that runs
the configure script that crashes.  Otherwise the script
would continue (and possibly give other error messages).
Try "file core", this should tell you which program produced
the core (I expect configure).  If this is indeed the case,
the bug is not in Python but in the shell.
Do you have a non-standard /bin/sh?
Which version of IRIX 6.5 are you running (try "versions
eoe.sw.base")?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 10:47

Message:
Logged In: YES 
user_id=6380

I see no reason why this should be priority 8, since all
evidence points towards the platform as the culprit. (IRIX
is notorious, though this is a new one.)

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

Comment By: Michael Hudson (mwh)
Date: 2002-05-10 04:41

Message:
Logged In: YES 
user_id=6656

Is there some way to tell which executable dumped the core
file?  It'd be "size core" on linux, dunno what on IRIX.

If it's /bin/sh, I'm not really sure what we can do...

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-09 14:18

Message:
Logged In: YES 
user_id=32232

I tried running with --disable-ipv6 and got exactly the same
crash. I edited 'configure' and added extra instructions to
have some idea what is happening. I modified fragment at
line 4361 from:
============================================
if test "${enable_ipv6+set}" = set; then
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else

============================================

to 

============================================
if test "${enable_ipv6+set}" = set; then
  echo "l. 4362"
else
  echo "l. 4364"
fi
if test "${enable_ipv6+set}" = set; then
  echo "l. 4367"
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else
  echo "l. 4383"
===========================================

The interesting part is that "l.4362" or "l.4364" are
printed depending on option "--disable-ipv6" being used, as
expected. However, the program crashes befere either
"l.4367" or "l.4383" is printed. For instance if I run
"./configure --disable-ipv6" the last lines of output are:

checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... l. 4362
Segmentation fault (core dumped)

The modified config is attached. Maybe there is some problem
with interpreting the 'configure' itself?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-08 04:45

Message:
Logged In: YES 
user_id=45365

The test for IPv6 support on your machine actually tries to run a program that uses IPv6. So, could it be that you have IPv6 support partially installed? For instance, you have the headers (does AF_INET6 occur anywhere in <sys/socket.h> or any flie it includes?) but not the corresponding C library.

This guess is easy to check: try a "./configure --disable-ipv6". If that works fine then the oabove is your problem, probably, and you also have a  workaround:-)

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-07 23:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 16:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Mon May 13 18:19:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 10:19:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E177JTf-0002Ho-00@usw-sf-web2.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 13:19

Message:
Logged In: YES 
user_id=32232

Looks that there is a workaround. I installed bash then
edited first line of 'configure' to use bash instead of
/bin/sh. Now configuration works. The only problem is that
bash 'configure' crashes too. So, this is only a solution if
you can get bash binaries.

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 12:40

Message:
Logged In: YES 
user_id=32232

"file core" outputs:
core:           IRIX N32 core dump of 'configure'

"versions eoe.sw.base" outputs
I  eoe                  03/05/2002  IRIX Execution
Environment, 6.5.15f
I  eoe.sw               03/05/2002  IRIX Execution
Environment Software
I  eoe.sw.base          03/05/2002  IRIX Base Execution
Environment

I am using /bin/sh that comes with the system (I am not the
system administrator). Looks to me that this is a problem
with /bin/sh. I tried to remove from configure whole block
that tests ipv6 but this just crushes configure same way on
the next test.Tried to put "echo" commands in side and
outside the in line 4360 (where the script crushes). Last
echo prints just before if, never inside, or after. As is
/bin/sh crashes while parsing the script(?).

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-05-13 11:30

Message:
Logged In: YES 
user_id=43607

The error message indicates that it is the shell that runs
the configure script that crashes.  Otherwise the script
would continue (and possibly give other error messages).
Try "file core", this should tell you which program produced
the core (I expect configure).  If this is indeed the case,
the bug is not in Python but in the shell.
Do you have a non-standard /bin/sh?
Which version of IRIX 6.5 are you running (try "versions
eoe.sw.base")?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 10:47

Message:
Logged In: YES 
user_id=6380

I see no reason why this should be priority 8, since all
evidence points towards the platform as the culprit. (IRIX
is notorious, though this is a new one.)

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

Comment By: Michael Hudson (mwh)
Date: 2002-05-10 04:41

Message:
Logged In: YES 
user_id=6656

Is there some way to tell which executable dumped the core
file?  It'd be "size core" on linux, dunno what on IRIX.

If it's /bin/sh, I'm not really sure what we can do...

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-09 14:18

Message:
Logged In: YES 
user_id=32232

I tried running with --disable-ipv6 and got exactly the same
crash. I edited 'configure' and added extra instructions to
have some idea what is happening. I modified fragment at
line 4361 from:
============================================
if test "${enable_ipv6+set}" = set; then
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else

============================================

to 

============================================
if test "${enable_ipv6+set}" = set; then
  echo "l. 4362"
else
  echo "l. 4364"
fi
if test "${enable_ipv6+set}" = set; then
  echo "l. 4367"
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else
  echo "l. 4383"
===========================================

The interesting part is that "l.4362" or "l.4364" are
printed depending on option "--disable-ipv6" being used, as
expected. However, the program crashes befere either
"l.4367" or "l.4383" is printed. For instance if I run
"./configure --disable-ipv6" the last lines of output are:

checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... l. 4362
Segmentation fault (core dumped)

The modified config is attached. Maybe there is some problem
with interpreting the 'configure' itself?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-08 04:45

Message:
Logged In: YES 
user_id=45365

The test for IPv6 support on your machine actually tries to run a program that uses IPv6. So, could it be that you have IPv6 support partially installed? For instance, you have the headers (does AF_INET6 occur anywhere in <sys/socket.h> or any flie it includes?) but not the corresponding C library.

This guess is easy to check: try a "./configure --disable-ipv6". If that works fine then the oabove is your problem, probably, and you also have a  workaround:-)

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-07 23:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 16:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Mon May 13 18:32:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 10:32:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E177Jgx-0002RL-00@usw-sf-web2.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 13:32

Message:
Logged In: YES 
user_id=6380

Closing the bug report, as there's nothing that Python can
do for you.

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 13:19

Message:
Logged In: YES 
user_id=32232

Looks that there is a workaround. I installed bash then
edited first line of 'configure' to use bash instead of
/bin/sh. Now configuration works. The only problem is that
bash 'configure' crashes too. So, this is only a solution if
you can get bash binaries.

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 12:40

Message:
Logged In: YES 
user_id=32232

"file core" outputs:
core:           IRIX N32 core dump of 'configure'

"versions eoe.sw.base" outputs
I  eoe                  03/05/2002  IRIX Execution
Environment, 6.5.15f
I  eoe.sw               03/05/2002  IRIX Execution
Environment Software
I  eoe.sw.base          03/05/2002  IRIX Base Execution
Environment

I am using /bin/sh that comes with the system (I am not the
system administrator). Looks to me that this is a problem
with /bin/sh. I tried to remove from configure whole block
that tests ipv6 but this just crushes configure same way on
the next test.Tried to put "echo" commands in side and
outside the in line 4360 (where the script crushes). Last
echo prints just before if, never inside, or after. As is
/bin/sh crashes while parsing the script(?).

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-05-13 11:30

Message:
Logged In: YES 
user_id=43607

The error message indicates that it is the shell that runs
the configure script that crashes.  Otherwise the script
would continue (and possibly give other error messages).
Try "file core", this should tell you which program produced
the core (I expect configure).  If this is indeed the case,
the bug is not in Python but in the shell.
Do you have a non-standard /bin/sh?
Which version of IRIX 6.5 are you running (try "versions
eoe.sw.base")?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 10:47

Message:
Logged In: YES 
user_id=6380

I see no reason why this should be priority 8, since all
evidence points towards the platform as the culprit. (IRIX
is notorious, though this is a new one.)

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

Comment By: Michael Hudson (mwh)
Date: 2002-05-10 04:41

Message:
Logged In: YES 
user_id=6656

Is there some way to tell which executable dumped the core
file?  It'd be "size core" on linux, dunno what on IRIX.

If it's /bin/sh, I'm not really sure what we can do...

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-09 14:18

Message:
Logged In: YES 
user_id=32232

I tried running with --disable-ipv6 and got exactly the same
crash. I edited 'configure' and added extra instructions to
have some idea what is happening. I modified fragment at
line 4361 from:
============================================
if test "${enable_ipv6+set}" = set; then
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else

============================================

to 

============================================
if test "${enable_ipv6+set}" = set; then
  echo "l. 4362"
else
  echo "l. 4364"
fi
if test "${enable_ipv6+set}" = set; then
  echo "l. 4367"
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else
  echo "l. 4383"
===========================================

The interesting part is that "l.4362" or "l.4364" are
printed depending on option "--disable-ipv6" being used, as
expected. However, the program crashes befere either
"l.4367" or "l.4383" is printed. For instance if I run
"./configure --disable-ipv6" the last lines of output are:

checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... l. 4362
Segmentation fault (core dumped)

The modified config is attached. Maybe there is some problem
with interpreting the 'configure' itself?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-08 04:45

Message:
Logged In: YES 
user_id=45365

The test for IPv6 support on your machine actually tries to run a program that uses IPv6. So, could it be that you have IPv6 support partially installed? For instance, you have the headers (does AF_INET6 occur anywhere in <sys/socket.h> or any flie it includes?) but not the corresponding C library.

This guess is easy to check: try a "./configure --disable-ipv6". If that works fine then the oabove is your problem, probably, and you also have a  workaround:-)

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-07 23:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 16:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Mon May 13 18:34:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 10:34:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-553736 ] thread_pthread.h on FreeBSD
Message-ID: <E177JiZ-0002F8-00@usw-sf-web3.sourceforge.net>

Bugs item #553736, was opened at 2002-05-08 10:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553736&group_id=5470

Category: Threads
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Sawyers (zc_andrew)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread_pthread.h on FreeBSD

Initial Comment:
The pthread setstacksize of 64K is too small for 
FreeBSD in some cases (i.e. specifically when running 
Zope/CMF).  The attached diff has worked on 3+ 
different production sites; though the setting of the 
stacksize to 128K was WAG.  It might be possible to 
still overflow the stacksize, though in all the sites 
using this change are no longer having problems.
I've spoken with Fred about this on a few occassions...
Thanks,
Andrew

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

>Comment By: Andrew Sawyers (zc_andrew)
Date: 2002-05-13 12:34

Message:
Logged In: YES 
user_id=538986

Yes, I definately think it's useful to have the change in 
the 2.1.x branches; specifically anyone running Zope could 
be exposed to this bug.
Thanks,
Andrew

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 09:53

Message:
Logged In: YES 
user_id=6380

It looks like a similar change has already been applied to
2.2 and beyond. Does that work for you? Do you think it
would be useful to backport this change to the Python 2.1.x
series?

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

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



From noreply@sourceforge.net  Mon May 13 21:32:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 13:32:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E177MUF-0005HF-00@usw-sf-web1.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 16:32

Message:
Logged In: YES 
user_id=32232

there's nothing that Python can do for me...
Oh well, back to Java.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 13:32

Message:
Logged In: YES 
user_id=6380

Closing the bug report, as there's nothing that Python can
do for you.

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 13:19

Message:
Logged In: YES 
user_id=32232

Looks that there is a workaround. I installed bash then
edited first line of 'configure' to use bash instead of
/bin/sh. Now configuration works. The only problem is that
bash 'configure' crashes too. So, this is only a solution if
you can get bash binaries.

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 12:40

Message:
Logged In: YES 
user_id=32232

"file core" outputs:
core:           IRIX N32 core dump of 'configure'

"versions eoe.sw.base" outputs
I  eoe                  03/05/2002  IRIX Execution
Environment, 6.5.15f
I  eoe.sw               03/05/2002  IRIX Execution
Environment Software
I  eoe.sw.base          03/05/2002  IRIX Base Execution
Environment

I am using /bin/sh that comes with the system (I am not the
system administrator). Looks to me that this is a problem
with /bin/sh. I tried to remove from configure whole block
that tests ipv6 but this just crushes configure same way on
the next test.Tried to put "echo" commands in side and
outside the in line 4360 (where the script crushes). Last
echo prints just before if, never inside, or after. As is
/bin/sh crashes while parsing the script(?).

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-05-13 11:30

Message:
Logged In: YES 
user_id=43607

The error message indicates that it is the shell that runs
the configure script that crashes.  Otherwise the script
would continue (and possibly give other error messages).
Try "file core", this should tell you which program produced
the core (I expect configure).  If this is indeed the case,
the bug is not in Python but in the shell.
Do you have a non-standard /bin/sh?
Which version of IRIX 6.5 are you running (try "versions
eoe.sw.base")?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 10:47

Message:
Logged In: YES 
user_id=6380

I see no reason why this should be priority 8, since all
evidence points towards the platform as the culprit. (IRIX
is notorious, though this is a new one.)

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

Comment By: Michael Hudson (mwh)
Date: 2002-05-10 04:41

Message:
Logged In: YES 
user_id=6656

Is there some way to tell which executable dumped the core
file?  It'd be "size core" on linux, dunno what on IRIX.

If it's /bin/sh, I'm not really sure what we can do...

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-09 14:18

Message:
Logged In: YES 
user_id=32232

I tried running with --disable-ipv6 and got exactly the same
crash. I edited 'configure' and added extra instructions to
have some idea what is happening. I modified fragment at
line 4361 from:
============================================
if test "${enable_ipv6+set}" = set; then
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else

============================================

to 

============================================
if test "${enable_ipv6+set}" = set; then
  echo "l. 4362"
else
  echo "l. 4364"
fi
if test "${enable_ipv6+set}" = set; then
  echo "l. 4367"
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else
  echo "l. 4383"
===========================================

The interesting part is that "l.4362" or "l.4364" are
printed depending on option "--disable-ipv6" being used, as
expected. However, the program crashes befere either
"l.4367" or "l.4383" is printed. For instance if I run
"./configure --disable-ipv6" the last lines of output are:

checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... l. 4362
Segmentation fault (core dumped)

The modified config is attached. Maybe there is some problem
with interpreting the 'configure' itself?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-08 04:45

Message:
Logged In: YES 
user_id=45365

The test for IPv6 support on your machine actually tries to run a program that uses IPv6. So, could it be that you have IPv6 support partially installed? For instance, you have the headers (does AF_INET6 occur anywhere in <sys/socket.h> or any flie it includes?) but not the corresponding C library.

This guess is easy to check: try a "./configure --disable-ipv6". If that works fine then the oabove is your problem, probably, and you also have a  workaround:-)

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-07 23:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 16:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Mon May 13 21:43:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 13:43:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-555360 ] UTF-16 BOM handling counterintuitive
Message-ID: <E177Mf2-0005LA-00@usw-sf-web4.sourceforge.net>

Bugs item #555360, was opened at 2002-05-13 11:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555360&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: M.-A. Lemburg (lemburg)
Summary: UTF-16 BOM handling counterintuitive

Initial Comment:
A search on "Unicode BOM" doesn't turn up anything related.

Sorry, I don't have a 2.2 or CVS to hand.  Easy enough
to replicate, anyway.  The UTF-16 codec happily
corrupts files by appending a BOM before writing
encoded text to the file:

bash-2.05a$ python
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import codecs
>>> f = codecs.open("/tmp/utf16","w","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = codecs.open("/tmp/utf16","a","utf-16")
>>> f.write(u"a")
>>> f.close()
>>> f = open("/tmp/utf16","r") 
>>> f.read()
'\xff\xfea\x00\xff\xfea\x00'

Oops.

Also, dir(codecs) shows BOM64* constants are defined
(to what purpose, I have no idea---Microsoft Word files
on Alpha, maybe?), but no BOM8, which actually has some
basis in the standards.  (I think the idea of a UTF-8
signature is a abomination, so you can leave it
out<wink>, but people who do use the BOM as signature
in UTF-8 files would find it useful.)  Hmm ...

>>> codecs.BOM_BE
'\xfe\xff'
>>> codecs.BOM64_BE
'\x00\x00\xfe\xff'
>>> codecs.BOM32_BE
'\xfe\xff'
>>> 

Urk!  I only count 32 bits in BOM64 and 16 bits in
BOM32!  Maybe BOM32_* was intended as an alias for
BOM_*, and BOM64_* was a continuation of the typo, as
it were?

I wonder if this is the right interface, actually. 
Wouldn't prefixBOM() and checkBOM() methods for streams
and strings make more sense?  prefixBOM should be
idempotent, and checkBOM would return either a codec
(with size and endianness determined) or a codec.BOM*
constant.

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-05-13 22:43

Message:
Logged In: YES 
user_id=89016

And if you're using a different encoding for the second 
open call, the data will really be corrupted:
f = codecs.open("/tmp/foo","w","utf-8")
f.write("ää")
f = codecs.open("/tmp/foo","a","latin-1")
f.write("ää")

But how should codec.open be able to determine that the 
file is always opened with the same encoding, or which 
encoding was used for the open call last time? And if it 
could would it have to read the content using the old 
encoding and rewrite it using the new encoding to keep the 
file consistent?

I agree that the BOM names are broken.

> I wonder if this is the right interface, actually. 
> Wouldn't prefixBOM() and checkBOM() methods for streams 
> and strings make more sense? prefixBOM should be 
> idempotent, and checkBOM would return either a codec 
> (with size and endianness determined) or a codec.BOM* 
> constant.

You should consider UTF-16 to be a stateful encoding, so if 
you want to do your output in multiple pieces you have to 
use a stateful encoder, i.e. a StreamWriter:

>>> import codecs, cStringIO as StringIO
>>> stream = StringIO.StringIO()
>>> writer = codecs.getwriter("utf-16")(stream)
>>> writer.write(u"a")
>>> writer.write(u"b") 
>>> stream.getvalue()
'\xff\xfea\x00b\x00'


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

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



From noreply@sourceforge.net  Mon May 13 22:44:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 14:44:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E177Nc5-0005P1-00@usw-sf-web2.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 22:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-05-13 23:44

Message:
Logged In: YES 
user_id=45365

I think you're misreading Guido's closing remark here, and it should be read as "there's nothing more the Python community can do for you". There's a workaround, and if you want the bug to be fixed you should pass it on to either the autoconf developers or SGI.

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 22:32

Message:
Logged In: YES 
user_id=32232

there's nothing that Python can do for me...
Oh well, back to Java.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 19:32

Message:
Logged In: YES 
user_id=6380

Closing the bug report, as there's nothing that Python can
do for you.

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 19:19

Message:
Logged In: YES 
user_id=32232

Looks that there is a workaround. I installed bash then
edited first line of 'configure' to use bash instead of
/bin/sh. Now configuration works. The only problem is that
bash 'configure' crashes too. So, this is only a solution if
you can get bash binaries.

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 18:40

Message:
Logged In: YES 
user_id=32232

"file core" outputs:
core:           IRIX N32 core dump of 'configure'

"versions eoe.sw.base" outputs
I  eoe                  03/05/2002  IRIX Execution
Environment, 6.5.15f
I  eoe.sw               03/05/2002  IRIX Execution
Environment Software
I  eoe.sw.base          03/05/2002  IRIX Base Execution
Environment

I am using /bin/sh that comes with the system (I am not the
system administrator). Looks to me that this is a problem
with /bin/sh. I tried to remove from configure whole block
that tests ipv6 but this just crushes configure same way on
the next test.Tried to put "echo" commands in side and
outside the in line 4360 (where the script crushes). Last
echo prints just before if, never inside, or after. As is
/bin/sh crashes while parsing the script(?).

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-05-13 17:30

Message:
Logged In: YES 
user_id=43607

The error message indicates that it is the shell that runs
the configure script that crashes.  Otherwise the script
would continue (and possibly give other error messages).
Try "file core", this should tell you which program produced
the core (I expect configure).  If this is indeed the case,
the bug is not in Python but in the shell.
Do you have a non-standard /bin/sh?
Which version of IRIX 6.5 are you running (try "versions
eoe.sw.base")?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 16:47

Message:
Logged In: YES 
user_id=6380

I see no reason why this should be priority 8, since all
evidence points towards the platform as the culprit. (IRIX
is notorious, though this is a new one.)

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

Comment By: Michael Hudson (mwh)
Date: 2002-05-10 10:41

Message:
Logged In: YES 
user_id=6656

Is there some way to tell which executable dumped the core
file?  It'd be "size core" on linux, dunno what on IRIX.

If it's /bin/sh, I'm not really sure what we can do...

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-09 20:18

Message:
Logged In: YES 
user_id=32232

I tried running with --disable-ipv6 and got exactly the same
crash. I edited 'configure' and added extra instructions to
have some idea what is happening. I modified fragment at
line 4361 from:
============================================
if test "${enable_ipv6+set}" = set; then
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else

============================================

to 

============================================
if test "${enable_ipv6+set}" = set; then
  echo "l. 4362"
else
  echo "l. 4364"
fi
if test "${enable_ipv6+set}" = set; then
  echo "l. 4367"
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else
  echo "l. 4383"
===========================================

The interesting part is that "l.4362" or "l.4364" are
printed depending on option "--disable-ipv6" being used, as
expected. However, the program crashes befere either
"l.4367" or "l.4383" is printed. For instance if I run
"./configure --disable-ipv6" the last lines of output are:

checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... l. 4362
Segmentation fault (core dumped)

The modified config is attached. Maybe there is some problem
with interpreting the 'configure' itself?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-08 10:45

Message:
Logged In: YES 
user_id=45365

The test for IPv6 support on your machine actually tries to run a program that uses IPv6. So, could it be that you have IPv6 support partially installed? For instance, you have the headers (does AF_INET6 occur anywhere in <sys/socket.h> or any flie it includes?) but not the corresponding C library.

This guess is easy to check: try a "./configure --disable-ipv6". If that works fine then the oabove is your problem, probably, and you also have a  workaround:-)

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-08 05:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 22:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Mon May 13 23:26:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 15:26:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-527139 ] random.gammavariate hosed
Message-ID: <E177OGi-0006Xj-00@usw-sf-web4.sourceforge.net>

Bugs item #527139, was opened at 2002-03-07 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527139&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: random.gammavariate hosed

Initial Comment:
Report from c.l.py; something is certainly wrong here, 
but will take some digging to figure out whether docs 
or code:

"""
From: Weet Vanniks
Sent: Thursday, March 07, 2002 11:14 AM
To: python-list@python.org
Subject: Bug in the standard module random ?


Hi,

The gammavariate function of the standard module is 
documented as taking two parameters, the first one 
alpha is required to be > -1 and the second beta is 
required to be >0.  However, examining the 
implementation, it seems that the requirement for 
alpha is to be >0.

In spite of this, I still have a problem since I 
called the gammavariate function with a parameter 
alpha equal to 0.2 and it fails logically on the 
following line:

ainv=_sqrt(2.0 * alpha - 1.0)

Apparently, the implementation requires alpha to be > 
0.5.  Am i missing something or is it a bug?
"""

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 17:26

Message:
Logged In: YES 
user_id=80475

Tim, is okay to commit the attached documentation patch and 
backport it to release22-maint?

Currently, the documentation mis-advertises the method name 
and domain.  It intended to say alpha>0; however, as the 
poster pointed out, the implementation fails for alpha<0.5.

For an immediate action, I think we ought to bring the docs 
into alignment with the implementation's actual name and 
domain.  See attached doc patch.

For a follow-up action, the implementation should be 
modified to handle the full domain, alpha>0.  This will 
take some research (meaning, I don't immediately see how to 
fix it <wink>).

Note 1:  I tested the current implementation and found that 
it does have the expected mean and variance for alpha in 
[.5, .75, 1, 2, 4, 8] and beta in [.1, .2, .4, .8, 1, 2, 4, 
8].  So, it looks like the code does function well when 
alpha >= 0.5.

Note 2:  My CRC handbook defines the gammavariate function 
with alpha offet by one, alpha > -1.  My college 
engineering statistics book defines it with alpha>0.  The 
executive summary is that the alpha offset is non-
standard.  This implementation uses the alpha>0 version.



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

Comment By: John Machin (sjmachin)
Date: 2002-03-09 21:09

Message:
Logged In: YES 
user_id=480138

Edited & revised version of my posts on c.l.py:

=== Point 1 =================
There is a doc problem. Some definitions of the gamma 
distribution define it (a) such that alpha > -1 and has the 
exponential distribution as a special case when alpha == 0; 
others take the tack (b) that the lower bound is zero and 
the exponential distribution is when alpha == 1.

Option (b) seems to be the most popular recently.
Example of (a): my very old probability textbook.
Example of (b):
http://www.nag.com/numeric/cl/manual/pdf/G05/g05ffc_cl05.pdf

Here we have the doc taking option (a) and the 
implementation taking
option (b).

N.B. the following is VERY relevant:
http://mail.python.org/pipermail/python-dev/2001-
January/012181.html

=== Point 2 =============
gammavariate() calls stdgamma() with arguments that include 
ainv, bbb, and ccc. stdgamma() uses those arguments only if 
alpha > 1.0. As the OP found, ainv is off the planet for 
alpha < 0.5.

stdgamma() is called (inside random.py) only once, from 
gammavariate()

The module exposes both gammavariate() and stdgamma() --- 
stdgamma() with those three extra args seems useless to me. 
It should not be an exposed function IMO.

=== Point 3 ========

The documentation says there is a gamma() but doesn't 
mention gammavariate() and stdgamma(). The exposed function 
should be called "gammavariate" (a) for consistency with 
other functions (b) to avoid the perceived need to explain 
that this "gamma" is not the gamma function!!!

[post-posting points]

=== Point 4 ==== 
Serendipitous coincidence: http://www.jstatsoft.org/v03/i03/

=== Point 5 ====

The algorithm that Python uses starts falling apart from 
underflow for small alpha. So does the algorithm in GSL 
(GNU Scientific Library). So does the algorithm in the 
Monty Python paper. The problem in all of them is that they 
do pow(random(), 1.0 / alpha) or exp(log(random) / alpha) 
or suchlike. For alpha == 0.00001 (say), the result is 
vanishingly small and most generated variates are == 0.0.  
Note that the Monty Python paper says "the rare but 
difficult case alpha < 1". Given the bug we currently have 
with alpha < 0.5, it would appear to be even rarer than 
using floats as dict keys :-) -- as we don't purport to be 
NAG or even GSL, I propose we do no more about this than a 
one-line warning in the doc. Perhaps the whole random 
module needs a "caveat emptor" up the front.

=== Point 6 ====
I shall prepare a patch for random.py and upload it real 
soon now.

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

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



From noreply@sourceforge.net  Mon May 13 23:33:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 15:33:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-527139 ] random.gammavariate hosed
Message-ID: <E177ONt-0006Rg-00@usw-sf-web1.sourceforge.net>

Bugs item #527139, was opened at 2002-03-07 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527139&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: random.gammavariate hosed

Initial Comment:
Report from c.l.py; something is certainly wrong here, 
but will take some digging to figure out whether docs 
or code:

"""
From: Weet Vanniks
Sent: Thursday, March 07, 2002 11:14 AM
To: python-list@python.org
Subject: Bug in the standard module random ?


Hi,

The gammavariate function of the standard module is 
documented as taking two parameters, the first one 
alpha is required to be > -1 and the second beta is 
required to be >0.  However, examining the 
implementation, it seems that the requirement for 
alpha is to be >0.

In spite of this, I still have a problem since I 
called the gammavariate function with a parameter 
alpha equal to 0.2 and it fails logically on the 
following line:

ainv=_sqrt(2.0 * alpha - 1.0)

Apparently, the implementation requires alpha to be > 
0.5.  Am i missing something or is it a bug?
"""

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

>Comment By: Tim Peters (tim_one)
Date: 2002-05-13 18:33

Message:
Logged In: YES 
user_id=31435

I can't foresee ever making time to look at this, so 
reassigned it to you.  Have fun <wink>.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 18:26

Message:
Logged In: YES 
user_id=80475

Tim, is okay to commit the attached documentation patch and 
backport it to release22-maint?

Currently, the documentation mis-advertises the method name 
and domain.  It intended to say alpha>0; however, as the 
poster pointed out, the implementation fails for alpha<0.5.

For an immediate action, I think we ought to bring the docs 
into alignment with the implementation's actual name and 
domain.  See attached doc patch.

For a follow-up action, the implementation should be 
modified to handle the full domain, alpha>0.  This will 
take some research (meaning, I don't immediately see how to 
fix it <wink>).

Note 1:  I tested the current implementation and found that 
it does have the expected mean and variance for alpha in 
[.5, .75, 1, 2, 4, 8] and beta in [.1, .2, .4, .8, 1, 2, 4, 
8].  So, it looks like the code does function well when 
alpha >= 0.5.

Note 2:  My CRC handbook defines the gammavariate function 
with alpha offet by one, alpha > -1.  My college 
engineering statistics book defines it with alpha>0.  The 
executive summary is that the alpha offset is non-
standard.  This implementation uses the alpha>0 version.



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

Comment By: John Machin (sjmachin)
Date: 2002-03-09 21:09

Message:
Logged In: YES 
user_id=480138

Edited & revised version of my posts on c.l.py:

=== Point 1 =================
There is a doc problem. Some definitions of the gamma 
distribution define it (a) such that alpha > -1 and has the 
exponential distribution as a special case when alpha == 0; 
others take the tack (b) that the lower bound is zero and 
the exponential distribution is when alpha == 1.

Option (b) seems to be the most popular recently.
Example of (a): my very old probability textbook.
Example of (b):
http://www.nag.com/numeric/cl/manual/pdf/G05/g05ffc_cl05.pdf

Here we have the doc taking option (a) and the 
implementation taking
option (b).

N.B. the following is VERY relevant:
http://mail.python.org/pipermail/python-dev/2001-
January/012181.html

=== Point 2 =============
gammavariate() calls stdgamma() with arguments that include 
ainv, bbb, and ccc. stdgamma() uses those arguments only if 
alpha > 1.0. As the OP found, ainv is off the planet for 
alpha < 0.5.

stdgamma() is called (inside random.py) only once, from 
gammavariate()

The module exposes both gammavariate() and stdgamma() --- 
stdgamma() with those three extra args seems useless to me. 
It should not be an exposed function IMO.

=== Point 3 ========

The documentation says there is a gamma() but doesn't 
mention gammavariate() and stdgamma(). The exposed function 
should be called "gammavariate" (a) for consistency with 
other functions (b) to avoid the perceived need to explain 
that this "gamma" is not the gamma function!!!

[post-posting points]

=== Point 4 ==== 
Serendipitous coincidence: http://www.jstatsoft.org/v03/i03/

=== Point 5 ====

The algorithm that Python uses starts falling apart from 
underflow for small alpha. So does the algorithm in GSL 
(GNU Scientific Library). So does the algorithm in the 
Monty Python paper. The problem in all of them is that they 
do pow(random(), 1.0 / alpha) or exp(log(random) / alpha) 
or suchlike. For alpha == 0.00001 (say), the result is 
vanishingly small and most generated variates are == 0.0.  
Note that the Monty Python paper says "the rare but 
difficult case alpha < 1". Given the bug we currently have 
with alpha < 0.5, it would appear to be even rarer than 
using floats as dict keys :-) -- as we don't purport to be 
NAG or even GSL, I propose we do no more about this than a 
one-line warning in the doc. Perhaps the whole random 
module needs a "caveat emptor" up the front.

=== Point 6 ====
I shall prepare a patch for random.py and upload it real 
soon now.

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

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



From noreply@sourceforge.net  Mon May 13 23:49:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 15:49:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-527139 ] random.gammavariate hosed
Message-ID: <E177Od2-0006oa-00@usw-sf-web4.sourceforge.net>

Bugs item #527139, was opened at 2002-03-07 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527139&group_id=5470

Category: Python Library
Group: None
Status: Open
>Resolution: Remind
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.gammavariate hosed

Initial Comment:
Report from c.l.py; something is certainly wrong here, 
but will take some digging to figure out whether docs 
or code:

"""
From: Weet Vanniks
Sent: Thursday, March 07, 2002 11:14 AM
To: python-list@python.org
Subject: Bug in the standard module random ?


Hi,

The gammavariate function of the standard module is 
documented as taking two parameters, the first one 
alpha is required to be > -1 and the second beta is 
required to be >0.  However, examining the 
implementation, it seems that the requirement for 
alpha is to be >0.

In spite of this, I still have a problem since I 
called the gammavariate function with a parameter 
alpha equal to 0.2 and it fails logically on the 
following line:

ainv=_sqrt(2.0 * alpha - 1.0)

Apparently, the implementation requires alpha to be > 
0.5.  Am i missing something or is it a bug?
"""

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 17:49

Message:
Logged In: YES 
user_id=80475

Committed documentation update:  librandom.tex 1.26 and 
1.25.18.1.

Leaving the bug open until a random.py gets patched to 
expand its domain.  Attaching test code to validate the 
patch.

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

Comment By: Tim Peters (tim_one)
Date: 2002-05-13 17:33

Message:
Logged In: YES 
user_id=31435

I can't foresee ever making time to look at this, so 
reassigned it to you.  Have fun <wink>.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 17:26

Message:
Logged In: YES 
user_id=80475

Tim, is okay to commit the attached documentation patch and 
backport it to release22-maint?

Currently, the documentation mis-advertises the method name 
and domain.  It intended to say alpha>0; however, as the 
poster pointed out, the implementation fails for alpha<0.5.

For an immediate action, I think we ought to bring the docs 
into alignment with the implementation's actual name and 
domain.  See attached doc patch.

For a follow-up action, the implementation should be 
modified to handle the full domain, alpha>0.  This will 
take some research (meaning, I don't immediately see how to 
fix it <wink>).

Note 1:  I tested the current implementation and found that 
it does have the expected mean and variance for alpha in 
[.5, .75, 1, 2, 4, 8] and beta in [.1, .2, .4, .8, 1, 2, 4, 
8].  So, it looks like the code does function well when 
alpha >= 0.5.

Note 2:  My CRC handbook defines the gammavariate function 
with alpha offet by one, alpha > -1.  My college 
engineering statistics book defines it with alpha>0.  The 
executive summary is that the alpha offset is non-
standard.  This implementation uses the alpha>0 version.



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

Comment By: John Machin (sjmachin)
Date: 2002-03-09 21:09

Message:
Logged In: YES 
user_id=480138

Edited & revised version of my posts on c.l.py:

=== Point 1 =================
There is a doc problem. Some definitions of the gamma 
distribution define it (a) such that alpha > -1 and has the 
exponential distribution as a special case when alpha == 0; 
others take the tack (b) that the lower bound is zero and 
the exponential distribution is when alpha == 1.

Option (b) seems to be the most popular recently.
Example of (a): my very old probability textbook.
Example of (b):
http://www.nag.com/numeric/cl/manual/pdf/G05/g05ffc_cl05.pdf

Here we have the doc taking option (a) and the 
implementation taking
option (b).

N.B. the following is VERY relevant:
http://mail.python.org/pipermail/python-dev/2001-
January/012181.html

=== Point 2 =============
gammavariate() calls stdgamma() with arguments that include 
ainv, bbb, and ccc. stdgamma() uses those arguments only if 
alpha > 1.0. As the OP found, ainv is off the planet for 
alpha < 0.5.

stdgamma() is called (inside random.py) only once, from 
gammavariate()

The module exposes both gammavariate() and stdgamma() --- 
stdgamma() with those three extra args seems useless to me. 
It should not be an exposed function IMO.

=== Point 3 ========

The documentation says there is a gamma() but doesn't 
mention gammavariate() and stdgamma(). The exposed function 
should be called "gammavariate" (a) for consistency with 
other functions (b) to avoid the perceived need to explain 
that this "gamma" is not the gamma function!!!

[post-posting points]

=== Point 4 ==== 
Serendipitous coincidence: http://www.jstatsoft.org/v03/i03/

=== Point 5 ====

The algorithm that Python uses starts falling apart from 
underflow for small alpha. So does the algorithm in GSL 
(GNU Scientific Library). So does the algorithm in the 
Monty Python paper. The problem in all of them is that they 
do pow(random(), 1.0 / alpha) or exp(log(random) / alpha) 
or suchlike. For alpha == 0.00001 (say), the result is 
vanishingly small and most generated variates are == 0.0.  
Note that the Monty Python paper says "the rare but 
difficult case alpha < 1". Given the bug we currently have 
with alpha < 0.5, it would appear to be even rarer than 
using floats as dict keys :-) -- as we don't purport to be 
NAG or even GSL, I propose we do no more about this than a 
one-line warning in the doc. Perhaps the whole random 
module needs a "caveat emptor" up the front.

=== Point 6 ====
I shall prepare a patch for random.py and upload it real 
soon now.

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

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



From noreply@sourceforge.net  Tue May 14 00:53:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 16:53:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-527139 ] random.gammavariate hosed
Message-ID: <E177Pcj-0007L1-00@usw-sf-web1.sourceforge.net>

Bugs item #527139, was opened at 2002-03-07 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527139&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.gammavariate hosed

Initial Comment:
Report from c.l.py; something is certainly wrong here, 
but will take some digging to figure out whether docs 
or code:

"""
From: Weet Vanniks
Sent: Thursday, March 07, 2002 11:14 AM
To: python-list@python.org
Subject: Bug in the standard module random ?


Hi,

The gammavariate function of the standard module is 
documented as taking two parameters, the first one 
alpha is required to be > -1 and the second beta is 
required to be >0.  However, examining the 
implementation, it seems that the requirement for 
alpha is to be >0.

In spite of this, I still have a problem since I 
called the gammavariate function with a parameter 
alpha equal to 0.2 and it fails logically on the 
following line:

ainv=_sqrt(2.0 * alpha - 1.0)

Apparently, the implementation requires alpha to be > 
0.5.  Am i missing something or is it a bug?
"""

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 18:53

Message:
Logged In: YES 
user_id=80475

Fixed the problem:  the temporary variables were being set 
outside of their guard.  See patch below.

Committed to random.py 1.29 and 1.26.6.1.
Updated librandom.tex to state:  alpha>0.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 17:49

Message:
Logged In: YES 
user_id=80475

Committed documentation update:  librandom.tex 1.26 and 
1.25.18.1.

Leaving the bug open until a random.py gets patched to 
expand its domain.  Attaching test code to validate the 
patch.

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

Comment By: Tim Peters (tim_one)
Date: 2002-05-13 17:33

Message:
Logged In: YES 
user_id=31435

I can't foresee ever making time to look at this, so 
reassigned it to you.  Have fun <wink>.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 17:26

Message:
Logged In: YES 
user_id=80475

Tim, is okay to commit the attached documentation patch and 
backport it to release22-maint?

Currently, the documentation mis-advertises the method name 
and domain.  It intended to say alpha>0; however, as the 
poster pointed out, the implementation fails for alpha<0.5.

For an immediate action, I think we ought to bring the docs 
into alignment with the implementation's actual name and 
domain.  See attached doc patch.

For a follow-up action, the implementation should be 
modified to handle the full domain, alpha>0.  This will 
take some research (meaning, I don't immediately see how to 
fix it <wink>).

Note 1:  I tested the current implementation and found that 
it does have the expected mean and variance for alpha in 
[.5, .75, 1, 2, 4, 8] and beta in [.1, .2, .4, .8, 1, 2, 4, 
8].  So, it looks like the code does function well when 
alpha >= 0.5.

Note 2:  My CRC handbook defines the gammavariate function 
with alpha offet by one, alpha > -1.  My college 
engineering statistics book defines it with alpha>0.  The 
executive summary is that the alpha offset is non-
standard.  This implementation uses the alpha>0 version.



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

Comment By: John Machin (sjmachin)
Date: 2002-03-09 21:09

Message:
Logged In: YES 
user_id=480138

Edited & revised version of my posts on c.l.py:

=== Point 1 =================
There is a doc problem. Some definitions of the gamma 
distribution define it (a) such that alpha > -1 and has the 
exponential distribution as a special case when alpha == 0; 
others take the tack (b) that the lower bound is zero and 
the exponential distribution is when alpha == 1.

Option (b) seems to be the most popular recently.
Example of (a): my very old probability textbook.
Example of (b):
http://www.nag.com/numeric/cl/manual/pdf/G05/g05ffc_cl05.pdf

Here we have the doc taking option (a) and the 
implementation taking
option (b).

N.B. the following is VERY relevant:
http://mail.python.org/pipermail/python-dev/2001-
January/012181.html

=== Point 2 =============
gammavariate() calls stdgamma() with arguments that include 
ainv, bbb, and ccc. stdgamma() uses those arguments only if 
alpha > 1.0. As the OP found, ainv is off the planet for 
alpha < 0.5.

stdgamma() is called (inside random.py) only once, from 
gammavariate()

The module exposes both gammavariate() and stdgamma() --- 
stdgamma() with those three extra args seems useless to me. 
It should not be an exposed function IMO.

=== Point 3 ========

The documentation says there is a gamma() but doesn't 
mention gammavariate() and stdgamma(). The exposed function 
should be called "gammavariate" (a) for consistency with 
other functions (b) to avoid the perceived need to explain 
that this "gamma" is not the gamma function!!!

[post-posting points]

=== Point 4 ==== 
Serendipitous coincidence: http://www.jstatsoft.org/v03/i03/

=== Point 5 ====

The algorithm that Python uses starts falling apart from 
underflow for small alpha. So does the algorithm in GSL 
(GNU Scientific Library). So does the algorithm in the 
Monty Python paper. The problem in all of them is that they 
do pow(random(), 1.0 / alpha) or exp(log(random) / alpha) 
or suchlike. For alpha == 0.00001 (say), the result is 
vanishingly small and most generated variates are == 0.0.  
Note that the Monty Python paper says "the rare but 
difficult case alpha < 1". Given the bug we currently have 
with alpha < 0.5, it would appear to be even rarer than 
using floats as dict keys :-) -- as we don't purport to be 
NAG or even GSL, I propose we do no more about this than a 
one-line warning in the doc. Perhaps the whole random 
module needs a "caveat emptor" up the front.

=== Point 6 ====
I shall prepare a patch for random.py and upload it real 
soon now.

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

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



From noreply@sourceforge.net  Tue May 14 00:53:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 16:53:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-527139 ] random.gammavariate hosed
Message-ID: <E177Pcr-0007L7-00@usw-sf-web1.sourceforge.net>

Bugs item #527139, was opened at 2002-03-07 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527139&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.gammavariate hosed

Initial Comment:
Report from c.l.py; something is certainly wrong here, 
but will take some digging to figure out whether docs 
or code:

"""
From: Weet Vanniks
Sent: Thursday, March 07, 2002 11:14 AM
To: python-list@python.org
Subject: Bug in the standard module random ?


Hi,

The gammavariate function of the standard module is 
documented as taking two parameters, the first one 
alpha is required to be > -1 and the second beta is 
required to be >0.  However, examining the 
implementation, it seems that the requirement for 
alpha is to be >0.

In spite of this, I still have a problem since I 
called the gammavariate function with a parameter 
alpha equal to 0.2 and it fails logically on the 
following line:

ainv=_sqrt(2.0 * alpha - 1.0)

Apparently, the implementation requires alpha to be > 
0.5.  Am i missing something or is it a bug?
"""

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 18:53

Message:
Logged In: YES 
user_id=80475

Fixed the problem:  the temporary variables were being set 
outside of their guard.  See patch below.

Committed to random.py 1.29 and 1.26.6.1.
Updated librandom.tex to state:  alpha>0.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 18:53

Message:
Logged In: YES 
user_id=80475

Fixed the problem:  the temporary variables were being set 
outside of their guard.  See patch below.

Committed to random.py 1.29 and 1.26.6.1.
Updated librandom.tex to state:  alpha>0.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 17:49

Message:
Logged In: YES 
user_id=80475

Committed documentation update:  librandom.tex 1.26 and 
1.25.18.1.

Leaving the bug open until a random.py gets patched to 
expand its domain.  Attaching test code to validate the 
patch.

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

Comment By: Tim Peters (tim_one)
Date: 2002-05-13 17:33

Message:
Logged In: YES 
user_id=31435

I can't foresee ever making time to look at this, so 
reassigned it to you.  Have fun <wink>.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 17:26

Message:
Logged In: YES 
user_id=80475

Tim, is okay to commit the attached documentation patch and 
backport it to release22-maint?

Currently, the documentation mis-advertises the method name 
and domain.  It intended to say alpha>0; however, as the 
poster pointed out, the implementation fails for alpha<0.5.

For an immediate action, I think we ought to bring the docs 
into alignment with the implementation's actual name and 
domain.  See attached doc patch.

For a follow-up action, the implementation should be 
modified to handle the full domain, alpha>0.  This will 
take some research (meaning, I don't immediately see how to 
fix it <wink>).

Note 1:  I tested the current implementation and found that 
it does have the expected mean and variance for alpha in 
[.5, .75, 1, 2, 4, 8] and beta in [.1, .2, .4, .8, 1, 2, 4, 
8].  So, it looks like the code does function well when 
alpha >= 0.5.

Note 2:  My CRC handbook defines the gammavariate function 
with alpha offet by one, alpha > -1.  My college 
engineering statistics book defines it with alpha>0.  The 
executive summary is that the alpha offset is non-
standard.  This implementation uses the alpha>0 version.



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

Comment By: John Machin (sjmachin)
Date: 2002-03-09 21:09

Message:
Logged In: YES 
user_id=480138

Edited & revised version of my posts on c.l.py:

=== Point 1 =================
There is a doc problem. Some definitions of the gamma 
distribution define it (a) such that alpha > -1 and has the 
exponential distribution as a special case when alpha == 0; 
others take the tack (b) that the lower bound is zero and 
the exponential distribution is when alpha == 1.

Option (b) seems to be the most popular recently.
Example of (a): my very old probability textbook.
Example of (b):
http://www.nag.com/numeric/cl/manual/pdf/G05/g05ffc_cl05.pdf

Here we have the doc taking option (a) and the 
implementation taking
option (b).

N.B. the following is VERY relevant:
http://mail.python.org/pipermail/python-dev/2001-
January/012181.html

=== Point 2 =============
gammavariate() calls stdgamma() with arguments that include 
ainv, bbb, and ccc. stdgamma() uses those arguments only if 
alpha > 1.0. As the OP found, ainv is off the planet for 
alpha < 0.5.

stdgamma() is called (inside random.py) only once, from 
gammavariate()

The module exposes both gammavariate() and stdgamma() --- 
stdgamma() with those three extra args seems useless to me. 
It should not be an exposed function IMO.

=== Point 3 ========

The documentation says there is a gamma() but doesn't 
mention gammavariate() and stdgamma(). The exposed function 
should be called "gammavariate" (a) for consistency with 
other functions (b) to avoid the perceived need to explain 
that this "gamma" is not the gamma function!!!

[post-posting points]

=== Point 4 ==== 
Serendipitous coincidence: http://www.jstatsoft.org/v03/i03/

=== Point 5 ====

The algorithm that Python uses starts falling apart from 
underflow for small alpha. So does the algorithm in GSL 
(GNU Scientific Library). So does the algorithm in the 
Monty Python paper. The problem in all of them is that they 
do pow(random(), 1.0 / alpha) or exp(log(random) / alpha) 
or suchlike. For alpha == 0.00001 (say), the result is 
vanishingly small and most generated variates are == 0.0.  
Note that the Monty Python paper says "the rare but 
difficult case alpha < 1". Given the bug we currently have 
with alpha < 0.5, it would appear to be even rarer than 
using floats as dict keys :-) -- as we don't purport to be 
NAG or even GSL, I propose we do no more about this than a 
one-line warning in the doc. Perhaps the whole random 
module needs a "caveat emptor" up the front.

=== Point 6 ====
I shall prepare a patch for random.py and upload it real 
soon now.

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

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



From noreply@sourceforge.net  Tue May 14 00:54:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 16:54:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-527139 ] random.gammavariate hosed
Message-ID: <E177PeU-0007M1-00@usw-sf-web1.sourceforge.net>

Bugs item #527139, was opened at 2002-03-07 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527139&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.gammavariate hosed

Initial Comment:
Report from c.l.py; something is certainly wrong here, 
but will take some digging to figure out whether docs 
or code:

"""
From: Weet Vanniks
Sent: Thursday, March 07, 2002 11:14 AM
To: python-list@python.org
Subject: Bug in the standard module random ?


Hi,

The gammavariate function of the standard module is 
documented as taking two parameters, the first one 
alpha is required to be > -1 and the second beta is 
required to be >0.  However, examining the 
implementation, it seems that the requirement for 
alpha is to be >0.

In spite of this, I still have a problem since I 
called the gammavariate function with a parameter 
alpha equal to 0.2 and it fails logically on the 
following line:

ainv=_sqrt(2.0 * alpha - 1.0)

Apparently, the implementation requires alpha to be > 
0.5.  Am i missing something or is it a bug?
"""

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 18:53

Message:
Logged In: YES 
user_id=80475

Fixed the problem:  the temporary variables were being set 
outside of their guard.  See patch below.

Committed to random.py 1.29 and 1.26.6.1.
Updated librandom.tex to state:  alpha>0.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 18:53

Message:
Logged In: YES 
user_id=80475

Fixed the problem:  the temporary variables were being set 
outside of their guard.  See patch below.

Committed to random.py 1.29 and 1.26.6.1.
Updated librandom.tex to state:  alpha>0.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 17:49

Message:
Logged In: YES 
user_id=80475

Committed documentation update:  librandom.tex 1.26 and 
1.25.18.1.

Leaving the bug open until a random.py gets patched to 
expand its domain.  Attaching test code to validate the 
patch.

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

Comment By: Tim Peters (tim_one)
Date: 2002-05-13 17:33

Message:
Logged In: YES 
user_id=31435

I can't foresee ever making time to look at this, so 
reassigned it to you.  Have fun <wink>.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 17:26

Message:
Logged In: YES 
user_id=80475

Tim, is okay to commit the attached documentation patch and 
backport it to release22-maint?

Currently, the documentation mis-advertises the method name 
and domain.  It intended to say alpha>0; however, as the 
poster pointed out, the implementation fails for alpha<0.5.

For an immediate action, I think we ought to bring the docs 
into alignment with the implementation's actual name and 
domain.  See attached doc patch.

For a follow-up action, the implementation should be 
modified to handle the full domain, alpha>0.  This will 
take some research (meaning, I don't immediately see how to 
fix it <wink>).

Note 1:  I tested the current implementation and found that 
it does have the expected mean and variance for alpha in 
[.5, .75, 1, 2, 4, 8] and beta in [.1, .2, .4, .8, 1, 2, 4, 
8].  So, it looks like the code does function well when 
alpha >= 0.5.

Note 2:  My CRC handbook defines the gammavariate function 
with alpha offet by one, alpha > -1.  My college 
engineering statistics book defines it with alpha>0.  The 
executive summary is that the alpha offset is non-
standard.  This implementation uses the alpha>0 version.



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

Comment By: John Machin (sjmachin)
Date: 2002-03-09 21:09

Message:
Logged In: YES 
user_id=480138

Edited & revised version of my posts on c.l.py:

=== Point 1 =================
There is a doc problem. Some definitions of the gamma 
distribution define it (a) such that alpha > -1 and has the 
exponential distribution as a special case when alpha == 0; 
others take the tack (b) that the lower bound is zero and 
the exponential distribution is when alpha == 1.

Option (b) seems to be the most popular recently.
Example of (a): my very old probability textbook.
Example of (b):
http://www.nag.com/numeric/cl/manual/pdf/G05/g05ffc_cl05.pdf

Here we have the doc taking option (a) and the 
implementation taking
option (b).

N.B. the following is VERY relevant:
http://mail.python.org/pipermail/python-dev/2001-
January/012181.html

=== Point 2 =============
gammavariate() calls stdgamma() with arguments that include 
ainv, bbb, and ccc. stdgamma() uses those arguments only if 
alpha > 1.0. As the OP found, ainv is off the planet for 
alpha < 0.5.

stdgamma() is called (inside random.py) only once, from 
gammavariate()

The module exposes both gammavariate() and stdgamma() --- 
stdgamma() with those three extra args seems useless to me. 
It should not be an exposed function IMO.

=== Point 3 ========

The documentation says there is a gamma() but doesn't 
mention gammavariate() and stdgamma(). The exposed function 
should be called "gammavariate" (a) for consistency with 
other functions (b) to avoid the perceived need to explain 
that this "gamma" is not the gamma function!!!

[post-posting points]

=== Point 4 ==== 
Serendipitous coincidence: http://www.jstatsoft.org/v03/i03/

=== Point 5 ====

The algorithm that Python uses starts falling apart from 
underflow for small alpha. So does the algorithm in GSL 
(GNU Scientific Library). So does the algorithm in the 
Monty Python paper. The problem in all of them is that they 
do pow(random(), 1.0 / alpha) or exp(log(random) / alpha) 
or suchlike. For alpha == 0.00001 (say), the result is 
vanishingly small and most generated variates are == 0.0.  
Note that the Monty Python paper says "the rare but 
difficult case alpha < 1". Given the bug we currently have 
with alpha < 0.5, it would appear to be even rarer than 
using floats as dict keys :-) -- as we don't purport to be 
NAG or even GSL, I propose we do no more about this than a 
one-line warning in the doc. Perhaps the whole random 
module needs a "caveat emptor" up the front.

=== Point 6 ====
I shall prepare a patch for random.py and upload it real 
soon now.

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

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



From noreply@sourceforge.net  Tue May 14 01:04:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 17:04:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-527139 ] random.gammavariate hosed
Message-ID: <E177Pnn-0006xy-00@usw-sf-web2.sourceforge.net>

Bugs item #527139, was opened at 2002-03-08 07:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527139&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.gammavariate hosed

Initial Comment:
Report from c.l.py; something is certainly wrong here, 
but will take some digging to figure out whether docs 
or code:

"""
From: Weet Vanniks
Sent: Thursday, March 07, 2002 11:14 AM
To: python-list@python.org
Subject: Bug in the standard module random ?


Hi,

The gammavariate function of the standard module is 
documented as taking two parameters, the first one 
alpha is required to be > -1 and the second beta is 
required to be >0.  However, examining the 
implementation, it seems that the requirement for 
alpha is to be >0.

In spite of this, I still have a problem since I 
called the gammavariate function with a parameter 
alpha equal to 0.2 and it fails logically on the 
following line:

ainv=_sqrt(2.0 * alpha - 1.0)

Apparently, the implementation requires alpha to be > 
0.5.  Am i missing something or is it a bug?
"""

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

Comment By: John Machin (sjmachin)
Date: 2002-05-14 10:04

Message:
Logged In: YES 
user_id=480138

Excuse my extreme ignorance of the way the process works, but might it be 
possible to consider patch number 529408, and Tim's comments on it?


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 09:53

Message:
Logged In: YES 
user_id=80475

Fixed the problem:  the temporary variables were being set 
outside of their guard.  See patch below.

Committed to random.py 1.29 and 1.26.6.1.
Updated librandom.tex to state:  alpha>0.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 09:53

Message:
Logged In: YES 
user_id=80475

Fixed the problem:  the temporary variables were being set 
outside of their guard.  See patch below.

Committed to random.py 1.29 and 1.26.6.1.
Updated librandom.tex to state:  alpha>0.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 08:49

Message:
Logged In: YES 
user_id=80475

Committed documentation update:  librandom.tex 1.26 and 
1.25.18.1.

Leaving the bug open until a random.py gets patched to 
expand its domain.  Attaching test code to validate the 
patch.

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

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 08:33

Message:
Logged In: YES 
user_id=31435

I can't foresee ever making time to look at this, so 
reassigned it to you.  Have fun <wink>.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 08:26

Message:
Logged In: YES 
user_id=80475

Tim, is okay to commit the attached documentation patch and 
backport it to release22-maint?

Currently, the documentation mis-advertises the method name 
and domain.  It intended to say alpha>0; however, as the 
poster pointed out, the implementation fails for alpha<0.5.

For an immediate action, I think we ought to bring the docs 
into alignment with the implementation's actual name and 
domain.  See attached doc patch.

For a follow-up action, the implementation should be 
modified to handle the full domain, alpha>0.  This will 
take some research (meaning, I don't immediately see how to 
fix it <wink>).

Note 1:  I tested the current implementation and found that 
it does have the expected mean and variance for alpha in 
[.5, .75, 1, 2, 4, 8] and beta in [.1, .2, .4, .8, 1, 2, 4, 
8].  So, it looks like the code does function well when 
alpha >= 0.5.

Note 2:  My CRC handbook defines the gammavariate function 
with alpha offet by one, alpha > -1.  My college 
engineering statistics book defines it with alpha>0.  The 
executive summary is that the alpha offset is non-
standard.  This implementation uses the alpha>0 version.



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

Comment By: John Machin (sjmachin)
Date: 2002-03-10 13:09

Message:
Logged In: YES 
user_id=480138

Edited & revised version of my posts on c.l.py:

=== Point 1 =================
There is a doc problem. Some definitions of the gamma 
distribution define it (a) such that alpha > -1 and has the 
exponential distribution as a special case when alpha == 0; 
others take the tack (b) that the lower bound is zero and 
the exponential distribution is when alpha == 1.

Option (b) seems to be the most popular recently.
Example of (a): my very old probability textbook.
Example of (b):
http://www.nag.com/numeric/cl/manual/pdf/G05/g05ffc_cl05.pdf

Here we have the doc taking option (a) and the 
implementation taking
option (b).

N.B. the following is VERY relevant:
http://mail.python.org/pipermail/python-dev/2001-
January/012181.html

=== Point 2 =============
gammavariate() calls stdgamma() with arguments that include 
ainv, bbb, and ccc. stdgamma() uses those arguments only if 
alpha > 1.0. As the OP found, ainv is off the planet for 
alpha < 0.5.

stdgamma() is called (inside random.py) only once, from 
gammavariate()

The module exposes both gammavariate() and stdgamma() --- 
stdgamma() with those three extra args seems useless to me. 
It should not be an exposed function IMO.

=== Point 3 ========

The documentation says there is a gamma() but doesn't 
mention gammavariate() and stdgamma(). The exposed function 
should be called "gammavariate" (a) for consistency with 
other functions (b) to avoid the perceived need to explain 
that this "gamma" is not the gamma function!!!

[post-posting points]

=== Point 4 ==== 
Serendipitous coincidence: http://www.jstatsoft.org/v03/i03/

=== Point 5 ====

The algorithm that Python uses starts falling apart from 
underflow for small alpha. So does the algorithm in GSL 
(GNU Scientific Library). So does the algorithm in the 
Monty Python paper. The problem in all of them is that they 
do pow(random(), 1.0 / alpha) or exp(log(random) / alpha) 
or suchlike. For alpha == 0.00001 (say), the result is 
vanishingly small and most generated variates are == 0.0.  
Note that the Monty Python paper says "the rare but 
difficult case alpha < 1". Given the bug we currently have 
with alpha < 0.5, it would appear to be even rarer than 
using floats as dict keys :-) -- as we don't purport to be 
NAG or even GSL, I propose we do no more about this than a 
one-line warning in the doc. Perhaps the whole random 
module needs a "caveat emptor" up the front.

=== Point 6 ====
I shall prepare a patch for random.py and upload it real 
soon now.

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

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



From noreply@sourceforge.net  Tue May 14 02:42:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 13 May 2002 18:42:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-553000 ] "./configure" crashes
Message-ID: <E177RL0-0007z8-00@usw-sf-web2.sourceforge.net>

Bugs item #553000, was opened at 2002-05-06 16:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553000&group_id=5470

Category: Build
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Jarek Sacha (jsacha)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "./configure" crashes

Initial Comment:
I am trying to built Python 2.2.1. I am getting a core
dump while running "./configure" on IRIX 6.5.
Last messages before the crash:

checking LDSHARED... ld  -shared -all
checking CCSHARED... -shared
checking LINKFORSHARED... 
checking CFLAGSFORSHARED... 
checking for dlopen in -ldl... yes
checking for shl_load in -ldld... no
checking for --with-libs... no
checking for --with-signal-module... yes
checking for --with-dec-threads... no
checking for --with-threads... yes
checking for _POSIX_THREADS in unistd.h... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... yes
checking if PTHREAD_SCOPE_SYSTEM is supported... no
checking for pthread_sigmask... yes
checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... Segmentation
fault (core dumped)

Please fing attached "config.log"

Regards,

Jarek Sacha

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

>Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 21:42

Message:
Logged In: YES 
user_id=32232

Meant to be a joke, apparently lousy. Personally, I found
Guido's last comment quite funny. I do use Python, Java, and
other languages. Each has its own strengths and depending on
circumstances may be a more efficient tool than others.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-13 17:44

Message:
Logged In: YES 
user_id=45365

I think you're misreading Guido's closing remark here, and it should be read as "there's nothing more the Python community can do for you". There's a workaround, and if you want the bug to be fixed you should pass it on to either the autoconf developers or SGI.

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 16:32

Message:
Logged In: YES 
user_id=32232

there's nothing that Python can do for me...
Oh well, back to Java.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 13:32

Message:
Logged In: YES 
user_id=6380

Closing the bug report, as there's nothing that Python can
do for you.

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 13:19

Message:
Logged In: YES 
user_id=32232

Looks that there is a workaround. I installed bash then
edited first line of 'configure' to use bash instead of
/bin/sh. Now configuration works. The only problem is that
bash 'configure' crashes too. So, this is only a solution if
you can get bash binaries.

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-13 12:40

Message:
Logged In: YES 
user_id=32232

"file core" outputs:
core:           IRIX N32 core dump of 'configure'

"versions eoe.sw.base" outputs
I  eoe                  03/05/2002  IRIX Execution
Environment, 6.5.15f
I  eoe.sw               03/05/2002  IRIX Execution
Environment Software
I  eoe.sw.base          03/05/2002  IRIX Base Execution
Environment

I am using /bin/sh that comes with the system (I am not the
system administrator). Looks to me that this is a problem
with /bin/sh. I tried to remove from configure whole block
that tests ipv6 but this just crushes configure same way on
the next test.Tried to put "echo" commands in side and
outside the in line 4360 (where the script crushes). Last
echo prints just before if, never inside, or after. As is
/bin/sh crashes while parsing the script(?).

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-05-13 11:30

Message:
Logged In: YES 
user_id=43607

The error message indicates that it is the shell that runs
the configure script that crashes.  Otherwise the script
would continue (and possibly give other error messages).
Try "file core", this should tell you which program produced
the core (I expect configure).  If this is indeed the case,
the bug is not in Python but in the shell.
Do you have a non-standard /bin/sh?
Which version of IRIX 6.5 are you running (try "versions
eoe.sw.base")?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 10:47

Message:
Logged In: YES 
user_id=6380

I see no reason why this should be priority 8, since all
evidence points towards the platform as the culprit. (IRIX
is notorious, though this is a new one.)

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

Comment By: Michael Hudson (mwh)
Date: 2002-05-10 04:41

Message:
Logged In: YES 
user_id=6656

Is there some way to tell which executable dumped the core
file?  It'd be "size core" on linux, dunno what on IRIX.

If it's /bin/sh, I'm not really sure what we can do...

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-09 14:18

Message:
Logged In: YES 
user_id=32232

I tried running with --disable-ipv6 and got exactly the same
crash. I edited 'configure' and added extra instructions to
have some idea what is happening. I modified fragment at
line 4361 from:
============================================
if test "${enable_ipv6+set}" = set; then
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else

============================================

to 

============================================
if test "${enable_ipv6+set}" = set; then
  echo "l. 4362"
else
  echo "l. 4364"
fi
if test "${enable_ipv6+set}" = set; then
  echo "l. 4367"
  enableval="$enable_ipv6"
   case "$enableval" in
  no)
       echo "$ac_t""no" 1>&6
       ipv6=no
       ;;
  *)   echo "$ac_t""yes" 1>&6
       cat >> confdefs.h <<\EOF
#define ENABLE_IPV6 1
EOF

       ipv6=yes
       ;;
  esac 
else
  echo "l. 4383"
===========================================

The interesting part is that "l.4362" or "l.4364" are
printed depending on option "--disable-ipv6" being used, as
expected. However, the program crashes befere either
"l.4367" or "l.4383" is printed. For instance if I run
"./configure --disable-ipv6" the last lines of output are:

checking for usconfig in -lmpc... no
checking for thr_create in -lthread... no
checking if --enable-ipv6 is specified... l. 4362
Segmentation fault (core dumped)

The modified config is attached. Maybe there is some problem
with interpreting the 'configure' itself?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-08 04:45

Message:
Logged In: YES 
user_id=45365

The test for IPv6 support on your machine actually tries to run a program that uses IPv6. So, could it be that you have IPv6 support partially installed? For instance, you have the headers (does AF_INET6 occur anywhere in <sys/socket.h> or any flie it includes?) but not the corresponding C library.

This guess is easy to check: try a "./configure --disable-ipv6". If that works fine then the oabove is your problem, probably, and you also have a  workaround:-)

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

Comment By: Jarek Sacha (jsacha)
Date: 2002-05-07 23:42

Message:
Logged In: YES 
user_id=32232

I tried "--without-gcc" and getting crash the same point.
Tried to use --verbose option, but did not get extra
information.

Do you know if there is a way to figure out what action is
made by 'configure' just before the crash

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-07 16:31

Message:
Logged In: YES 
user_id=45365

I can't repeat this, but I don't have gcc installed (and from your config.log it appears that you do).

Try building with configure --without-gcc.

There have always been problems with gcc on Irix, which is why I've stayed away from it, but I'm not sure whether building Python with gcc on Irix is supported (I found no notes to the contrary). So, I'm leaving this report open and someone else can pick it up, if they like.

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

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



From noreply@sourceforge.net  Tue May 14 08:19:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 00:19:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E177Wb9-0002u6-00@usw-sf-web2.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 06:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

>Category: Documentation
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Rouse (p_rouse)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

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

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



From noreply@sourceforge.net  Tue May 14 08:30:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 00:30:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-555779 ] import user doesn't work with CGIs
Message-ID: <E177WlD-0003pq-00@usw-sf-web4.sourceforge.net>

Bugs item #555779, was opened at 2002-05-14 07:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555779&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Hansen (ixokai_)
Assigned to: Nobody/Anonymous (nobody)
Summary: import user doesn't work with CGIs

Initial Comment:
 I'm doing some CGI scripts for a job, and I've made   
some a series of libraries i'd like them to share--   
but I don't wish them to be publically installed into   
site-packages. The user mechanism seems quite suited   
to the task of easily modifying sys.path to include a   
more "private" library directory.   
  
Unfortunately, it won't work in this secnario,  
because there is no $HOME environment variable set  
when Apache calls the script.  
  
Here are a couple small patches to make it work if  
the scripts are running SUID or with Apache's suEXEC  
feature.  

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

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



From noreply@sourceforge.net  Tue May 14 08:40:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 00:40:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E177Wuf-00036O-00@usw-sf-web3.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 06:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Rouse (p_rouse)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 02:40

Message:
Logged In: YES 
user_id=80475

Barry, is this the intended behavior or should the comment 
in the docs be eliminated?  The conversation in 
www.python.org/sf/463330 was not clear to me on this point.

Confirmed:
>>> import base64
>>> v = base64.encodestring('hello!')
>>> w = base64.encodestring('hello!\n')
>>> v == w, v , w
(False, 'aGVsbG8h\n', 'aGVsbG8hCg==\n')

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

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



From noreply@sourceforge.net  Tue May 14 09:53:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 01:53:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-555810 ] removing extensions without admin rights
Message-ID: <E177Y3M-0003w9-00@usw-sf-web2.sourceforge.net>

Bugs item #555810, was opened at 2002-05-14 10:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555810&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: removing extensions without admin rights

Initial Comment:
It is possible for ordinary users to remove python
extensions installed from bdist_wininst by an admin.
bdist_wininst should check permissions before allowing
this.

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

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



From noreply@sourceforge.net  Tue May 14 09:56:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 01:56:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-555812 ] installing extension w/o admin rights
Message-ID: <E177Y6D-0003yP-00@usw-sf-web2.sourceforge.net>

Bugs item #555812, was opened at 2002-05-14 10:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555812&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Thomas Heller (theller)
Summary: installing extension w/o admin rights

Initial Comment:
Users without admin rights can run bdist_wininst
installers, but they cannot set the registry entries
for uninstallation.
bdist_wininst should in this case write into the
HKEY_CURRENT_USER branch instead of HKEY_LOCAL_MACHINE.

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

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



From noreply@sourceforge.net  Tue May 14 10:06:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 02:06:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E177YGb-0004vB-00@usw-sf-web4.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 10:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

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

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



From noreply@sourceforge.net  Tue May 14 11:10:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 03:10:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E177ZGP-0005cM-00@usw-sf-web4.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 19:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 20:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


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

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



From noreply@sourceforge.net  Tue May 14 11:51:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 03:51:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-550364 ] Version number handling
Message-ID: <E177Zu2-00064Z-00@usw-sf-web4.sourceforge.net>

Bugs item #550364, was opened at 2002-04-29 15:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550364&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: Version number handling

Initial Comment:
A while ago, Tim Peters mentioned in a check-in message:

"Change the version string from "2.2+" to "2.3a0".  distutils 
peels off
the first 3 characters of this string in several places, so for as 
long
as they remain "2.2" it confuses the heck out of attempts to 
build 2.3 stuff using distutils."

It's true; distutils does sys.version[:3] in a few places.
The attached patch factors this out so it'll be easier to 
change.  

(There's also a Python development issue here, namely when
the version number gets bumped in the CVS tree.)


 


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 05:51

Message:
Logged In: YES 
user_id=80475

Nice factoring.

Would it be more bulletproof to use sys.version_info 
instead of sys.version[:3]?  Perhaps, wrap it in try/except 
to catch versions before Py2.0.

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

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



From noreply@sourceforge.net  Tue May 14 12:28:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 04:28:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-500539 ] Inaccuracy(?) in tutorial section 9.2
Message-ID: <E177aTN-0006VK-00@usw-sf-web4.sourceforge.net>

Bugs item #500539, was opened at 2002-01-07 15:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Andrew Koenig (arkoenig)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Inaccuracy(?) in tutorial section 9.2

Initial Comment:
Section 9.2 paragraph 3 defines a namespace as a
mapping from names to objects.  Perhaps I'm being picky
here, but isn't a namespace a mapping from names to
object references?  For example, doesn't executing the
expression "modname.the_answer = 42" as shown in
paragraph 5 cause modname.the_answer to refer to a
different object than the one to which it referred
previously, rather than affecting the specific object
to which modname.the_answer refers?

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 06:28

Message:
Logged In: YES 
user_id=80475

Any objections to closing this one?

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

Comment By: Andrew Koenig (arkoenig)
Date: 2002-01-08 15:27

Message:
Logged In: YES 
user_id=418174

Aha! -- Now I understand.  You're thinking of a namespace 
as a collection of named references to objects that can be 
searched associatively by name :-)  Moreover, the name-
reference relation is bijective.  That is, if I write

a = 3
b = 4

then there is a unique entity -- which I have been calling 
a reference -- associated with `a' and another such entity 
associated with `b'.  Moreover, because the relation is 
bijective, the entity with which `a' is associated is not 
associated with any other name, and similarly for `b'.  
Because of this bijectivity, there is never any reason to 
think about this entity separately from its name, and 
therefore you do not need a separate term for it.

Incidentally, C++ uses both the term `lvalue' and 
`reference,' with `lvalue' denoting a syntactic context and 
`reference' denoting a particular property of types.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-08 15:10

Message:
Logged In: YES 
user_id=6380

I read everything. :-) Let me butt in here. (I also probably
wrote that section in the tutorial. :-)

I know Algol-68 and am familiar with its use of the term
"reference". Fred probably isn't and thinks of references as
equivalent to pointers; but I'm sure he's familiar with the
C term "l-value" which is C's name for what Algol-68 cals a
reference. (I don't know what C++ calls it these days; isn't
reference a specific thing involving an & operator there?)

Python just doesn't use the concept of "object reference" in
the same way as Algol-68 uses it. I mean it when I say that
a namespace maps names to objects! The difference is that I
consider assignment a change to the mapping. It can't be a
change to a "reference" (in the Algol-68 sense) since the
reference may not yet exist (if the name wasn't bound
before).

Also, Python *definitely* doesn't have the concept of a
reference to a reference (C's ** types, Algol-68's ref ref).
While there most definitely is a piece of memory holding an
object pointer in the *implementation* of Python's
namespaces, and in other collections of objects like lists,
there's no way in Python to talk about that piece of memory
in a unified way. You'd have to say "the name X in mapping
Y" or "the index K in sequence L" or something like that.

I hope this helps everyone's understanding!

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-08 11:49

Message:
Logged In: YES 
user_id=3066

Re-opened for further consideration when I have more time.

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

Comment By: Andrew Koenig (arkoenig)
Date: 2002-01-08 11:22

Message:
Logged In: YES 
user_id=418174

Actually, I was saying the opposite.  Executing "x = 42"
certainly does not mutate the object that was previously
associated with x, but rather causes x to be associated with
a new object, namely 42.  To me that suggests that 42 is an
object and x is something else, perhaps a way of accessing
an object.

You are right that this kind of confusion is common among
people who write about C++, but you are not right that I
used C++ as the basis for my original comment.  I first
became aware of the importance of distinguishing between
objects and object references in Algol 68, many years before
C++ ever existed, and there is a wonderful piece in Lewis
Carroll's ``Through the Looking Glass'' about this very
issue.

More seriously, if there is no program I can ever write that
is capable of distinguishing between an object and an object
reference, then it doesn't matter.  However, I think I can
write such a program:

a = [42]; b = [a, a]

Now it doesn't make sense to say that b[0] and b[1] are the
same object, because they aren't.  Proof:  If I execute
b[0]=79, b[1] is still [42].  On the other hand, b[0] and
b[1] do refer to the same object, and it is that distinction
that I am suggesting that it is important to draw.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-08 10:20

Message:
Logged In: YES 
user_id=3066

There is no difference between an object reference and an
object in Python code, so the statement in the tutorial is
correct.  The behavior you are describing as "object"
behavior seems to assume that there's some sort of
assignment  which mutates the object which is the current
value of the assignment target, but there is no such
operator.  I can see where this might be confusing for
programmers coming from C++, though.  ;-)

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

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



From noreply@sourceforge.net  Tue May 14 12:33:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 04:33:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-500539 ] Inaccuracy(?) in tutorial section 9.2
Message-ID: <E177aYR-0005mv-00@usw-sf-web2.sourceforge.net>

Bugs item #500539, was opened at 2002-01-07 15:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500539&group_id=5470

Category: Documentation
Group: Not a Bug
>Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Andrew Koenig (arkoenig)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Inaccuracy(?) in tutorial section 9.2

Initial Comment:
Section 9.2 paragraph 3 defines a namespace as a
mapping from names to objects.  Perhaps I'm being picky
here, but isn't a namespace a mapping from names to
object references?  For example, doesn't executing the
expression "modname.the_answer = 42" as shown in
paragraph 5 cause modname.the_answer to refer to a
different object than the one to which it referred
previously, rather than affecting the specific object
to which modname.the_answer refers?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 07:28

Message:
Logged In: YES 
user_id=80475

Any objections to closing this one?

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

Comment By: Andrew Koenig (arkoenig)
Date: 2002-01-08 15:27

Message:
Logged In: YES 
user_id=418174

Aha! -- Now I understand.  You're thinking of a namespace 
as a collection of named references to objects that can be 
searched associatively by name :-)  Moreover, the name-
reference relation is bijective.  That is, if I write

a = 3
b = 4

then there is a unique entity -- which I have been calling 
a reference -- associated with `a' and another such entity 
associated with `b'.  Moreover, because the relation is 
bijective, the entity with which `a' is associated is not 
associated with any other name, and similarly for `b'.  
Because of this bijectivity, there is never any reason to 
think about this entity separately from its name, and 
therefore you do not need a separate term for it.

Incidentally, C++ uses both the term `lvalue' and 
`reference,' with `lvalue' denoting a syntactic context and 
`reference' denoting a particular property of types.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-08 15:10

Message:
Logged In: YES 
user_id=6380

I read everything. :-) Let me butt in here. (I also probably
wrote that section in the tutorial. :-)

I know Algol-68 and am familiar with its use of the term
"reference". Fred probably isn't and thinks of references as
equivalent to pointers; but I'm sure he's familiar with the
C term "l-value" which is C's name for what Algol-68 cals a
reference. (I don't know what C++ calls it these days; isn't
reference a specific thing involving an & operator there?)

Python just doesn't use the concept of "object reference" in
the same way as Algol-68 uses it. I mean it when I say that
a namespace maps names to objects! The difference is that I
consider assignment a change to the mapping. It can't be a
change to a "reference" (in the Algol-68 sense) since the
reference may not yet exist (if the name wasn't bound
before).

Also, Python *definitely* doesn't have the concept of a
reference to a reference (C's ** types, Algol-68's ref ref).
While there most definitely is a piece of memory holding an
object pointer in the *implementation* of Python's
namespaces, and in other collections of objects like lists,
there's no way in Python to talk about that piece of memory
in a unified way. You'd have to say "the name X in mapping
Y" or "the index K in sequence L" or something like that.

I hope this helps everyone's understanding!

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-08 11:49

Message:
Logged In: YES 
user_id=3066

Re-opened for further consideration when I have more time.

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

Comment By: Andrew Koenig (arkoenig)
Date: 2002-01-08 11:22

Message:
Logged In: YES 
user_id=418174

Actually, I was saying the opposite.  Executing "x = 42"
certainly does not mutate the object that was previously
associated with x, but rather causes x to be associated with
a new object, namely 42.  To me that suggests that 42 is an
object and x is something else, perhaps a way of accessing
an object.

You are right that this kind of confusion is common among
people who write about C++, but you are not right that I
used C++ as the basis for my original comment.  I first
became aware of the importance of distinguishing between
objects and object references in Algol 68, many years before
C++ ever existed, and there is a wonderful piece in Lewis
Carroll's ``Through the Looking Glass'' about this very
issue.

More seriously, if there is no program I can ever write that
is capable of distinguishing between an object and an object
reference, then it doesn't matter.  However, I think I can
write such a program:

a = [42]; b = [a, a]

Now it doesn't make sense to say that b[0] and b[1] are the
same object, because they aren't.  Proof:  If I execute
b[0]=79, b[1] is still [42].  On the other hand, b[0] and
b[1] do refer to the same object, and it is that distinction
that I am suggesting that it is important to draw.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-01-08 10:20

Message:
Logged In: YES 
user_id=3066

There is no difference between an object reference and an
object in Python code, so the statement in the tutorial is
correct.  The behavior you are describing as "object"
behavior seems to assume that there's some sort of
assignment  which mutates the object which is the current
value of the assignment target, but there is no such
operator.  I can see where this might be confusing for
programmers coming from C++, though.  ;-)

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

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



From noreply@sourceforge.net  Tue May 14 13:06:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 05:06:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E177b4j-0007V6-00@usw-sf-web1.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 19:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 22:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 20:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


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

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



From noreply@sourceforge.net  Tue May 14 13:37:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 05:37:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-555900 ] telnetlib: UnboundLocalError
Message-ID: <E177bYJ-0006b7-00@usw-sf-web3.sourceforge.net>

Bugs item #555900, was opened at 2002-05-14 14:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555900&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeroen Vloothuis (slmm)
Assigned to: Nobody/Anonymous (nobody)
Summary: telnetlib: UnboundLocalError

Initial Comment:
When i run my script i get this:

Traceback (most recent call last):
  File "./zis.py", line 13, in ?
    tn.read_until("Usernummer : ")
  File "/usr/lib/python2.2/telnetlib.py", line 297, in
read_until
    self.process_rawq()
  File "/usr/lib/python2.2/telnetlib.py", line 424, in
process_rawq
    self.msg('IAC %d not recognized' % ord(opt))
UnboundLocalError: local variable 'opt' referenced
before assignment

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

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



From noreply@sourceforge.net  Tue May 14 14:52:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 06:52:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E177cjY-00087r-00@usw-sf-web4.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 07:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Rouse (p_rouse)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 09:52

Message:
Logged In: YES 
user_id=12800

The intended behavior is irrelevant <wink>.  Since this is
how the base64 module works, it needs to be correctly
documented.  It's way too late to be changing this behavior,
as broken as some might think it is.:)

Note that the email package has an RFC 2045-2047 compliant
base64 encoding module called email.base64MIME.  It
currently isn't documented (but will be before 2.3 is released).

Reassigning to Fred so he can correct the base64 documentation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 03:40

Message:
Logged In: YES 
user_id=80475

Barry, is this the intended behavior or should the comment 
in the docs be eliminated?  The conversation in 
www.python.org/sf/463330 was not clear to me on this point.

Confirmed:
>>> import base64
>>> v = base64.encodestring('hello!')
>>> w = base64.encodestring('hello!\n')
>>> v == w, v , w
(False, 'aGVsbG8h\n', 'aGVsbG8hCg==\n')

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

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



From noreply@sourceforge.net  Tue May 14 17:11:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 09:11:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E177etQ-0000aC-00@usw-sf-web2.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 06:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Rouse (p_rouse)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 11:11

Message:
Logged In: YES 
user_id=80475

Fred, is the attached patch okay to commit to 2.3 and 
release 22-maint?

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 08:52

Message:
Logged In: YES 
user_id=12800

The intended behavior is irrelevant <wink>.  Since this is
how the base64 module works, it needs to be correctly
documented.  It's way too late to be changing this behavior,
as broken as some might think it is.:)

Note that the email package has an RFC 2045-2047 compliant
base64 encoding module called email.base64MIME.  It
currently isn't documented (but will be before 2.3 is released).

Reassigning to Fred so he can correct the base64 documentation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 02:40

Message:
Logged In: YES 
user_id=80475

Barry, is this the intended behavior or should the comment 
in the docs be eliminated?  The conversation in 
www.python.org/sf/463330 was not clear to me on this point.

Confirmed:
>>> import base64
>>> v = base64.encodestring('hello!')
>>> w = base64.encodestring('hello!\n')
>>> v == w, v , w
(False, 'aGVsbG8h\n', 'aGVsbG8hCg==\n')

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

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



From noreply@sourceforge.net  Tue May 14 17:41:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 09:41:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E177fMF-0001ff-00@usw-sf-web4.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 11:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

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

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



From noreply@sourceforge.net  Tue May 14 19:04:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 11:04:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-553736 ] thread_pthread.h on FreeBSD
Message-ID: <E177ges-0003He-00@usw-sf-web1.sourceforge.net>

Bugs item #553736, was opened at 2002-05-08 11:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553736&group_id=5470

Category: Threads
Group: Python 2.1.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Sawyers (zc_andrew)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread_pthread.h on FreeBSD

Initial Comment:
The pthread setstacksize of 64K is too small for 
FreeBSD in some cases (i.e. specifically when running 
Zope/CMF).  The attached diff has worked on 3+ 
different production sites; though the setting of the 
stacksize to 128K was WAG.  It might be possible to 
still overflow the stacksize, though in all the sites 
using this change are no longer having problems.
I've spoken with Fred about this on a few occassions...
Thanks,
Andrew

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-14 14:04

Message:
Logged In: YES 
user_id=6380

Casey Duncan says he can live with it for 2.1.x, so I'm
closing this as Won't Fix.

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

Comment By: Andrew Sawyers (zc_andrew)
Date: 2002-05-13 13:34

Message:
Logged In: YES 
user_id=538986

Yes, I definately think it's useful to have the change in 
the 2.1.x branches; specifically anyone running Zope could 
be exposed to this bug.
Thanks,
Andrew

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 10:53

Message:
Logged In: YES 
user_id=6380

It looks like a similar change has already been applied to
2.2 and beyond. Does that work for you? Do you think it
would be useful to backport this change to the Python 2.1.x
series?

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

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



From noreply@sourceforge.net  Tue May 14 20:12:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 12:12:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-553736 ] thread_pthread.h on FreeBSD
Message-ID: <E177hjE-0002h3-00@usw-sf-web2.sourceforge.net>

Bugs item #553736, was opened at 2002-05-08 11:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=553736&group_id=5470

Category: Threads
Group: Python 2.1.2
>Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Andrew Sawyers (zc_andrew)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread_pthread.h on FreeBSD

Initial Comment:
The pthread setstacksize of 64K is too small for 
FreeBSD in some cases (i.e. specifically when running 
Zope/CMF).  The attached diff has worked on 3+ 
different production sites; though the setting of the 
stacksize to 128K was WAG.  It might be possible to 
still overflow the stacksize, though in all the sites 
using this change are no longer having problems.
I've spoken with Fred about this on a few occassions...
Thanks,
Andrew

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-14 15:12

Message:
Logged In: YES 
user_id=6380

Oops, Casey didn't speak for everyone. Reopened as a 2.1.4
task.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-14 14:04

Message:
Logged In: YES 
user_id=6380

Casey Duncan says he can live with it for 2.1.x, so I'm
closing this as Won't Fix.

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

Comment By: Andrew Sawyers (zc_andrew)
Date: 2002-05-13 13:34

Message:
Logged In: YES 
user_id=538986

Yes, I definately think it's useful to have the change in 
the 2.1.x branches; specifically anyone running Zope could 
be exposed to this bug.
Thanks,
Andrew

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-13 10:53

Message:
Logged In: YES 
user_id=6380

It looks like a similar change has already been applied to
2.2 and beyond. Does that work for you? Do you think it
would be useful to backport this change to the Python 2.1.x
series?

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

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



From noreply@sourceforge.net  Tue May 14 22:45:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 14:45:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-556121 ] Assertion failed (eval_code2)
Message-ID: <E177k75-0004TZ-00@usw-sf-web2.sourceforge.net>

Bugs item #556121, was opened at 2002-05-14 21:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556121&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Stuart (rstuart)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion failed (eval_code2)

Initial Comment:
This has already been described in bug 499788:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470

That bug is closed.  The version mentioned in that bug is 2.1.2, and I guess they were hoping it 
went away in 2.1.3.  I am using 2.1.3 and still have the problem.

The problem
-----------
I have a fresh install of Zope.  In Zope I open the Tutorial.  It fails and this error appears in 
/var/log/zope:

python2.1: Python/ceval.c:695: eval_code2: Assertion `(stack_pointer - f->f_valuestack) 
<=f->f_stacksize' failed.

Software versions
-----------------
Distribution: RedHat 7.2
http://www.python.org/ftp/python/2.1.3/rpms/rh7.2/python2.1-2.1.3-1.i386.rpm
http://www.python.org/ftp/python/2.1.3/rpms/rh7.2/python2.1-devel-2.1.3-1.i386.rpm
http://www.taupro.com/static/RPMs/Zope-2.4.3-1.i386.rpm
http://www.taupro.com/static/RPMs/Zope-pcgi-2.4.3-1.i386.rpm

I also have Python 1.5.2 and Python 2.2 installed, but Zope should not be using them.



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

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



From noreply@sourceforge.net  Tue May 14 22:53:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 14:53:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-506647 ] random.cunifvariate() incorrect?
Message-ID: <E177kEp-0005Hy-00@usw-sf-web4.sourceforge.net>

Bugs item #506647, was opened at 2002-01-21 16:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506647&group_id=5470

Category: Python Library
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Maciej Kalisiak (abcdefghijklmno)
>Assigned to: Martin v. Löwis (loewis)
Summary: random.cunifvariate() incorrect?

Initial Comment:
random.cunifvariate() currently is defined as:
  return (mean + arc * (self.random() - 0.5)) % _pi

First of all, this returns values in the range [0, pi)
due to the modulus, which really makes it a
semi-circular distribution, not circular (but I'm not a
mathie, so perhaps I'm wrong).

I think the normalizing step ("% _pi", or whatever this
gets changed to) should probably be mentioned in the
documentation for this function; it caught me by
surprise, and I expect it will catch some others too.  

With this defintion, the function returns a random
value in the range [mean-arc/2, mean+arc/2).  The docs
say that arc, like mean, can only be in the range
[0,pi].  This would imply that one cannot get values in
the other half of the circle, i.e. [pi, 2*pi).  Since
there doesn't seem to be anything stopping the caller
from using an arc in [0,2*pi], perhaps the
documentation should be updated?


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 16:53

Message:
Logged In: YES 
user_id=80475

Martin, please approve the patch and I'll load it for Py2.3.

The docs don't match the function and the actual behavior 
is weird.  Thinking in degrees, calling with a mean of 175 
and an arc of 20 returns {x | 0<x<5 or 165<x<180} with an 
expected mean of 130 instead of the specified mean of 175.

Google reports no non-Python examples of cunifvariate so 
there is no standard to match against.

The patch removes the Pi normalization in the 
implementation and removes the superfluous domain 
restriction in the docs.

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

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



From noreply@sourceforge.net  Tue May 14 23:15:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 15:15:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E177kZv-0004pt-00@usw-sf-web3.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

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

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



From noreply@sourceforge.net  Wed May 15 01:44:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 17:44:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E177muU-0007sT-00@usw-sf-web1.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 11:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 19:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



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

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 17:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

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

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



From noreply@sourceforge.net  Wed May 15 03:40:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 19:40:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E177ohz-0000Zw-00@usw-sf-web1.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 07:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Rouse (p_rouse)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-14 22:40

Message:
Logged In: YES 
user_id=3066

Barry, you're the MIME guru, tell Raymond whether he should
check in his patch.  ;-)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 12:11

Message:
Logged In: YES 
user_id=80475

Fred, is the attached patch okay to commit to 2.3 and 
release 22-maint?

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 09:52

Message:
Logged In: YES 
user_id=12800

The intended behavior is irrelevant <wink>.  Since this is
how the base64 module works, it needs to be correctly
documented.  It's way too late to be changing this behavior,
as broken as some might think it is.:)

Note that the email package has an RFC 2045-2047 compliant
base64 encoding module called email.base64MIME.  It
currently isn't documented (but will be before 2.3 is released).

Reassigning to Fred so he can correct the base64 documentation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 03:40

Message:
Logged In: YES 
user_id=80475

Barry, is this the intended behavior or should the comment 
in the docs be eliminated?  The conversation in 
www.python.org/sf/463330 was not clear to me on this point.

Confirmed:
>>> import base64
>>> v = base64.encodestring('hello!')
>>> w = base64.encodestring('hello!\n')
>>> v == w, v , w
(False, 'aGVsbG8h\n', 'aGVsbG8hCg==\n')

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

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



From noreply@sourceforge.net  Wed May 15 05:51:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 May 2002 21:51:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E177qlO-0001CE-00@usw-sf-web4.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 07:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Rouse (p_rouse)
Assigned to: Barry Warsaw (bwarsaw)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-15 00:51

Message:
Logged In: YES 
user_id=12800

I'm not sure the patch is sufficient.  You need to at least
explain that a newline is always added to the output.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-14 22:40

Message:
Logged In: YES 
user_id=3066

Barry, you're the MIME guru, tell Raymond whether he should
check in his patch.  ;-)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 12:11

Message:
Logged In: YES 
user_id=80475

Fred, is the attached patch okay to commit to 2.3 and 
release 22-maint?

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 09:52

Message:
Logged In: YES 
user_id=12800

The intended behavior is irrelevant <wink>.  Since this is
how the base64 module works, it needs to be correctly
documented.  It's way too late to be changing this behavior,
as broken as some might think it is.:)

Note that the email package has an RFC 2045-2047 compliant
base64 encoding module called email.base64MIME.  It
currently isn't documented (but will be before 2.3 is released).

Reassigning to Fred so he can correct the base64 documentation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 03:40

Message:
Logged In: YES 
user_id=80475

Barry, is this the intended behavior or should the comment 
in the docs be eliminated?  The conversation in 
www.python.org/sf/463330 was not clear to me on this point.

Confirmed:
>>> import base64
>>> v = base64.encodestring('hello!')
>>> w = base64.encodestring('hello!\n')
>>> v == w, v , w
(False, 'aGVsbG8h\n', 'aGVsbG8hCg==\n')

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

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



From noreply@sourceforge.net  Wed May 15 09:13:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 01:13:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E177tuy-0002bf-00@usw-sf-web2.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 06:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Rouse (p_rouse)
Assigned to: Barry Warsaw (bwarsaw)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 03:13

Message:
Logged In: YES 
user_id=80475

Please approve the new patch.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 23:51

Message:
Logged In: YES 
user_id=12800

I'm not sure the patch is sufficient.  You need to at least
explain that a newline is always added to the output.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-14 21:40

Message:
Logged In: YES 
user_id=3066

Barry, you're the MIME guru, tell Raymond whether he should
check in his patch.  ;-)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 11:11

Message:
Logged In: YES 
user_id=80475

Fred, is the attached patch okay to commit to 2.3 and 
release 22-maint?

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 08:52

Message:
Logged In: YES 
user_id=12800

The intended behavior is irrelevant <wink>.  Since this is
how the base64 module works, it needs to be correctly
documented.  It's way too late to be changing this behavior,
as broken as some might think it is.:)

Note that the email package has an RFC 2045-2047 compliant
base64 encoding module called email.base64MIME.  It
currently isn't documented (but will be before 2.3 is released).

Reassigning to Fred so he can correct the base64 documentation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 02:40

Message:
Logged In: YES 
user_id=80475

Barry, is this the intended behavior or should the comment 
in the docs be eliminated?  The conversation in 
www.python.org/sf/463330 was not clear to me on this point.

Confirmed:
>>> import base64
>>> v = base64.encodestring('hello!')
>>> w = base64.encodestring('hello!\n')
>>> v == w, v , w
(False, 'aGVsbG8h\n', 'aGVsbG8hCg==\n')

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

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



From noreply@sourceforge.net  Wed May 15 12:00:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 04:00:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-506647 ] random.cunifvariate() incorrect?
Message-ID: <E177wVp-0005Cb-00@usw-sf-web4.sourceforge.net>

Bugs item #506647, was opened at 2002-01-21 22:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506647&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Maciej Kalisiak (abcdefghijklmno)
>Assigned to: Tim Peters (tim_one)
Summary: random.cunifvariate() incorrect?

Initial Comment:
random.cunifvariate() currently is defined as:
  return (mean + arc * (self.random() - 0.5)) % _pi

First of all, this returns values in the range [0, pi)
due to the modulus, which really makes it a
semi-circular distribution, not circular (but I'm not a
mathie, so perhaps I'm wrong).

I think the normalizing step ("% _pi", or whatever this
gets changed to) should probably be mentioned in the
documentation for this function; it caught me by
surprise, and I expect it will catch some others too.  

With this defintion, the function returns a random
value in the range [mean-arc/2, mean+arc/2).  The docs
say that arc, like mean, can only be in the range
[0,pi].  This would imply that one cannot get values in
the other half of the circle, i.e. [pi, 2*pi).  Since
there doesn't seem to be anything stopping the caller
from using an arc in [0,2*pi], perhaps the
documentation should be updated?


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 13:00

Message:
Logged In: YES 
user_id=21627

I'm not qualified to comment on the correctness of this
change, so unassigning it. Maybe Tim knows what a
cunifvariate is?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 23:53

Message:
Logged In: YES 
user_id=80475

Martin, please approve the patch and I'll load it for Py2.3.

The docs don't match the function and the actual behavior 
is weird.  Thinking in degrees, calling with a mean of 175 
and an arc of 20 returns {x | 0<x<5 or 165<x<180} with an 
expected mean of 130 instead of the specified mean of 175.

Google reports no non-Python examples of cunifvariate so 
there is no standard to match against.

The patch removes the Pi normalization in the 
implementation and removes the superfluous domain 
restriction in the docs.

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

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



From noreply@sourceforge.net  Wed May 15 13:04:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 05:04:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E177xWX-0006gC-00@usw-sf-web1.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 11:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 14:04

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 14:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 12:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


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

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



From noreply@sourceforge.net  Wed May 15 14:57:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 06:57:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E177zHT-0006Y0-00@usw-sf-web2.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 07:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Rouse (p_rouse)
Assigned to: Barry Warsaw (bwarsaw)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-15 09:57

Message:
Logged In: YES 
user_id=12800

Actually, I realized encodestring() is a bit more subtle
than that.  I think what it actually does is "return a
string containing one or more lines of base64-encoded data"
always including an extra trailing newline.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 04:13

Message:
Logged In: YES 
user_id=80475

Please approve the new patch.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-15 00:51

Message:
Logged In: YES 
user_id=12800

I'm not sure the patch is sufficient.  You need to at least
explain that a newline is always added to the output.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-14 22:40

Message:
Logged In: YES 
user_id=3066

Barry, you're the MIME guru, tell Raymond whether he should
check in his patch.  ;-)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 12:11

Message:
Logged In: YES 
user_id=80475

Fred, is the attached patch okay to commit to 2.3 and 
release 22-maint?

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 09:52

Message:
Logged In: YES 
user_id=12800

The intended behavior is irrelevant <wink>.  Since this is
how the base64 module works, it needs to be correctly
documented.  It's way too late to be changing this behavior,
as broken as some might think it is.:)

Note that the email package has an RFC 2045-2047 compliant
base64 encoding module called email.base64MIME.  It
currently isn't documented (but will be before 2.3 is released).

Reassigning to Fred so he can correct the base64 documentation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 03:40

Message:
Logged In: YES 
user_id=80475

Barry, is this the intended behavior or should the comment 
in the docs be eliminated?  The conversation in 
www.python.org/sf/463330 was not clear to me on this point.

Confirmed:
>>> import base64
>>> v = base64.encodestring('hello!')
>>> w = base64.encodestring('hello!\n')
>>> v == w, v , w
(False, 'aGVsbG8h\n', 'aGVsbG8hCg==\n')

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

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



From noreply@sourceforge.net  Wed May 15 15:59:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 07:59:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-556370 ] Expat improperly described in setup.py
Message-ID: <E1780FT-00081x-00@usw-sf-web4.sourceforge.net>

Bugs item #556370, was opened at 2002-05-15 09:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556370&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expat improperly described in setup.py

Initial Comment:
This bug is for 2.2.1, not 2.2.1 "candidate."

Setup.py in the home directory explains how to obtain
the current version of the expat package. However, it
gives the path to the private home page of the original
developer. The package at that location is incorrect;
the correct package is at
<http://sourceforge.net/projects/expat/>.

The stale package introduces several problems:
* The package does not create the "expat.h" in
/usr/include that setup.py looks for
* The stale package does not automatically create libaries

The correct package fixes both of these problems.

SUGGESTED FIX:

* Modify setup.py to point to correct package. Note:
configure, make, make install will install the correct
libaries and include files.

* Modify README to include information about expat.
Speaking as a user, there's no reason for me to suspect
that I have to read setup.py to find out which modules
might not be included when I compile! Information about
expat belongs in README, so that I understand what
packages might be necessary for me to install before I
run the installation process.

HELP:

If you wish to assign me to rewrite this documentation,
I can do so; I'm a little reluctant to touch setup.py
because I only have a Linux setup here, and touching
any py module means testing across builds IMHO.


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

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



From noreply@sourceforge.net  Wed May 15 15:57:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 07:57:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E1780Dx-0007Kv-00@usw-sf-web3.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 06:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Rouse (p_rouse)
Assigned to: Barry Warsaw (bwarsaw)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 09:57

Message:
Logged In: YES 
user_id=80475

Inserted new wording into patch below.
Do you also want this backported to release22-maint?



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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-15 08:57

Message:
Logged In: YES 
user_id=12800

Actually, I realized encodestring() is a bit more subtle
than that.  I think what it actually does is "return a
string containing one or more lines of base64-encoded data"
always including an extra trailing newline.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 03:13

Message:
Logged In: YES 
user_id=80475

Please approve the new patch.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 23:51

Message:
Logged In: YES 
user_id=12800

I'm not sure the patch is sufficient.  You need to at least
explain that a newline is always added to the output.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-14 21:40

Message:
Logged In: YES 
user_id=3066

Barry, you're the MIME guru, tell Raymond whether he should
check in his patch.  ;-)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 11:11

Message:
Logged In: YES 
user_id=80475

Fred, is the attached patch okay to commit to 2.3 and 
release 22-maint?

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 08:52

Message:
Logged In: YES 
user_id=12800

The intended behavior is irrelevant <wink>.  Since this is
how the base64 module works, it needs to be correctly
documented.  It's way too late to be changing this behavior,
as broken as some might think it is.:)

Note that the email package has an RFC 2045-2047 compliant
base64 encoding module called email.base64MIME.  It
currently isn't documented (but will be before 2.3 is released).

Reassigning to Fred so he can correct the base64 documentation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 02:40

Message:
Logged In: YES 
user_id=80475

Barry, is this the intended behavior or should the comment 
in the docs be eliminated?  The conversation in 
www.python.org/sf/463330 was not clear to me on this point.

Confirmed:
>>> import base64
>>> v = base64.encodestring('hello!')
>>> w = base64.encodestring('hello!\n')
>>> v == w, v , w
(False, 'aGVsbG8h\n', 'aGVsbG8hCg==\n')

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

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



From noreply@sourceforge.net  Wed May 15 16:06:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 08:06:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E1780M2-00087T-00@usw-sf-web4.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 07:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Rouse (p_rouse)
Assigned to: Barry Warsaw (bwarsaw)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-15 11:06

Message:
Logged In: YES 
user_id=3066

I think the patch should apply to both release21-maint and
release22-maint as well as the trunk.  I don't think this
describes a recently introduced behavior in the base64 module.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 10:57

Message:
Logged In: YES 
user_id=80475

Inserted new wording into patch below.
Do you also want this backported to release22-maint?



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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-15 09:57

Message:
Logged In: YES 
user_id=12800

Actually, I realized encodestring() is a bit more subtle
than that.  I think what it actually does is "return a
string containing one or more lines of base64-encoded data"
always including an extra trailing newline.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 04:13

Message:
Logged In: YES 
user_id=80475

Please approve the new patch.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-15 00:51

Message:
Logged In: YES 
user_id=12800

I'm not sure the patch is sufficient.  You need to at least
explain that a newline is always added to the output.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-14 22:40

Message:
Logged In: YES 
user_id=3066

Barry, you're the MIME guru, tell Raymond whether he should
check in his patch.  ;-)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 12:11

Message:
Logged In: YES 
user_id=80475

Fred, is the attached patch okay to commit to 2.3 and 
release 22-maint?

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 09:52

Message:
Logged In: YES 
user_id=12800

The intended behavior is irrelevant <wink>.  Since this is
how the base64 module works, it needs to be correctly
documented.  It's way too late to be changing this behavior,
as broken as some might think it is.:)

Note that the email package has an RFC 2045-2047 compliant
base64 encoding module called email.base64MIME.  It
currently isn't documented (but will be before 2.3 is released).

Reassigning to Fred so he can correct the base64 documentation.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 03:40

Message:
Logged In: YES 
user_id=80475

Barry, is this the intended behavior or should the comment 
in the docs be eliminated?  The conversation in 
www.python.org/sf/463330 was not clear to me on this point.

Confirmed:
>>> import base64
>>> v = base64.encodestring('hello!')
>>> w = base64.encodestring('hello!\n')
>>> v == w, v , w
(False, 'aGVsbG8h\n', 'aGVsbG8hCg==\n')

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

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



From noreply@sourceforge.net  Wed May 15 15:44:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 07:44:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E17800W-00006s-00@usw-sf-web1.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 10:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

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

>Comment By: Graham Horler (grahamh)
Date: 2002-05-15 15:44

Message:
Logged In: YES 
user_id=543663

Re Loewis:
Not sure what you mean, perhaps an example of the 
problem from me would help:

In C:
    char buf[256], strbuf[256];
    int ret, fd;
    fd = open(...)
    ret = ioctl(fd, IOCTL_NUMBER, buf);
    strncpy(strbuf, buf, ret);

This is impossible with the current fcntl module:
    buf = "X" * struct.calcsize("256s")
    buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf)
    # The positive ioctl() return value is lost, and
    # hence I dont know how much of buf is significant

Extract from asm/unistd.h:

#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

So positive values are valid, but are being lost.

Anthony's patch looks good (thanks, I have not had a 
chance to test it myself yet), and the above example would 
be:
    buf = "X" * struct.calcsize("256s")
    ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf)
    strbuf = buf[:ret] # Result!

Now, to test my understanding of your last comment about 
array objects Loewis, do you mean:
- pass in a mutable list that gets changed in place to [ret, 
buf]
- return (ret, buf) if called like this: ioctl(fd, IOC, [buf])
- or something else - please give example.

Thanks people.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 13:04

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 13:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 11:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


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

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



From noreply@sourceforge.net  Wed May 15 16:12:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 08:12:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-556374 ] web site does not have 2.2.1 bug group
Message-ID: <E1780SA-0008D2-00@usw-sf-web4.sourceforge.net>

Bugs item #556374, was opened at 2002-05-15 10:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556374&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: web site does not have 2.2.1 bug group

Initial Comment:
The sourceforge web site, used to report bugs, does not
have a "2.2.1" group for bug submissions, just "2.2.1
candidate."

I am filing this based on the assumtion, which I gather
from reading the python.org web pages, that the 2001-04
release of 2.2.1 available for download is not a
candidate - it is a release.

I agree that I may be nit-picking here -- but I just
submitted a bug, and it'd be nice to know that it
hasn't been discarded because it's for a stale release.
Having the right group provides positive feedback to
bug reporters.

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

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



From noreply@sourceforge.net  Wed May 15 16:17:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 08:17:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-556374 ] web site does not have 2.2.1 bug group
Message-ID: <E1780WV-0007ZT-00@usw-sf-web3.sourceforge.net>

Bugs item #556374, was opened at 2002-05-15 11:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556374&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: web site does not have 2.2.1 bug group

Initial Comment:
The sourceforge web site, used to report bugs, does not
have a "2.2.1" group for bug submissions, just "2.2.1
candidate."

I am filing this based on the assumtion, which I gather
from reading the python.org web pages, that the 2001-04
release of 2.2.1 available for download is not a
candidate - it is a release.

I agree that I may be nit-picking here -- but I just
submitted a bug, and it'd be nice to know that it
hasn't been discarded because it's for a stale release.
Having the right group provides positive feedback to
bug reporters.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-15 11:17

Message:
Logged In: YES 
user_id=3066

Added "Python 2.2.1" group to the  bug tracker -- thanks!

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

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



From noreply@sourceforge.net  Wed May 15 16:33:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 08:33:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-548693 ] Missing or wrong index entries
Message-ID: <E1780mG-0000hw-00@usw-sf-web1.sourceforge.net>

Bugs item #548693, was opened at 2002-04-25 12:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548693&group_id=5470

Category: Documentation
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Missing or wrong index entries

Initial Comment:
As repoted by Cliff Wells in private email to me:

The dictionary's 'setdefault' method is not if the
library index.

'has_key' is listed in the library index as Queue
method, but the entry refers to "Hash, Btree, and
Record Objects" of bsddb.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-15 11:33

Message:
Logged In: YES 
user_id=3066

Looks good to me.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 21:39

Message:
Logged In: YES 
user_id=80475

Okay to check-in?
Also, okay to back-patch to release22-maint (without the pop
() method)?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 21:34

Message:
Logged In: YES 
user_id=80475

Added patch to index missing methods.
Note, has_key was already fixed by Py2.2.

Fred, is this patch okay to commit?

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

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



From noreply@sourceforge.net  Wed May 15 16:38:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 08:38:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E1780r0-0007o0-00@usw-sf-web3.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 09:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

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

>Comment By: Michael Hudson (mwh)
Date: 2002-05-15 15:38

Message:
Logged In: YES 
user_id=6656

grahamh: I think Martin understood you fine.

Remember that arrays are mutable, whereas strings are not.

So the idea would be that you'd write

buf = array.array('c', '\000'*256)
ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf)

then the first "ret" bytes of "buf" would be valid.

However this possibly breaks backwards compatibility, as you
can already pass arrays into the ioctl function and they are
not modified.

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

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 14:44

Message:
Logged In: YES 
user_id=543663

Re Loewis:
Not sure what you mean, perhaps an example of the 
problem from me would help:

In C:
    char buf[256], strbuf[256];
    int ret, fd;
    fd = open(...)
    ret = ioctl(fd, IOCTL_NUMBER, buf);
    strncpy(strbuf, buf, ret);

This is impossible with the current fcntl module:
    buf = "X" * struct.calcsize("256s")
    buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf)
    # The positive ioctl() return value is lost, and
    # hence I dont know how much of buf is significant

Extract from asm/unistd.h:

#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

So positive values are valid, but are being lost.

Anthony's patch looks good (thanks, I have not had a 
chance to test it myself yet), and the above example would 
be:
    buf = "X" * struct.calcsize("256s")
    ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf)
    strbuf = buf[:ret] # Result!

Now, to test my understanding of your last comment about 
array objects Loewis, do you mean:
- pass in a mutable list that gets changed in place to [ret, 
buf]
- return (ret, buf) if called like this: ioctl(fd, IOC, [buf])
- or something else - please give example.

Thanks people.

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

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

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 12:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 10:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


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

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



From noreply@sourceforge.net  Wed May 15 16:51:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 08:51:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-548693 ] Missing or wrong index entries
Message-ID: <E17813c-0000vv-00@usw-sf-web1.sourceforge.net>

Bugs item #548693, was opened at 2002-04-25 11:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548693&group_id=5470

Category: Documentation
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Missing or wrong index entries

Initial Comment:
As repoted by Cliff Wells in private email to me:

The dictionary's 'setdefault' method is not if the
library index.

'has_key' is listed in the library index as Queue
method, but the entry refers to "Hash, Btree, and
Record Objects" of bsddb.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 10:51

Message:
Logged In: YES 
user_id=80475

Committed as libstdtypes.tex 1.93 and 1.80.6.9.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-15 10:33

Message:
Logged In: YES 
user_id=3066

Looks good to me.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 20:39

Message:
Logged In: YES 
user_id=80475

Okay to check-in?
Also, okay to back-patch to release22-maint (without the pop
() method)?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-12 20:34

Message:
Logged In: YES 
user_id=80475

Added patch to index missing methods.
Note, has_key was already fixed by Py2.2.

Fred, is this patch okay to commit?

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

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



From noreply@sourceforge.net  Wed May 15 17:28:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 09:28:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E1781dj-0008KF-00@usw-sf-web2.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 07:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Paul Rouse (p_rouse)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-15 12:28

Message:
Logged In: YES 
user_id=12800

Fred's right, the behavior is long standing.  I'm good with
the patch.  Reassigning to Raymond for application of patch,
who should close this report once that's done.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-15 11:06

Message:
Logged In: YES 
user_id=3066

I think the patch should apply to both release21-maint and
release22-maint as well as the trunk.  I don't think this
describes a recently introduced behavior in the base64 module.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 10:57

Message:
Logged In: YES 
user_id=80475

Inserted new wording into patch below.
Do you also want this backported to release22-maint?



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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-15 09:57

Message:
Logged In: YES 
user_id=12800

Actually, I realized encodestring() is a bit more subtle
than that.  I think what it actually does is "return a
string containing one or more lines of base64-encoded data"
always including an extra trailing newline.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 04:13

Message:
Logged In: YES 
user_id=80475

Please approve the new patch.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-15 00:51

Message:
Logged In: YES 
user_id=12800

I'm not sure the patch is sufficient.  You need to at least
explain that a newline is always added to the output.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-14 22:40

Message:
Logged In: YES 
user_id=3066

Barry, you're the MIME guru, tell Raymond whether he should
check in his patch.  ;-)

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 12:11

Message:
Logged In: YES 
user_id=80475

Fred, is the attached patch okay to commit to 2.3 and 
release 22-maint?

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 09:52

Message:
Logged In: YES 
user_id=12800

The intended behavior is irrelevant <wink>.  Since this is
how the base64 module works, it needs to be correctly
documented.  It's way too late to be changing this behavior,
as broken as some might think it is.:)

Note that the email package has an RFC 2045-2047 compliant
base64 encoding module called email.base64MIME.  It
currently isn't documented (but will be before 2.3 is released).

Reassigning to Fred so he can correct the base64 documentation.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 03:40

Message:
Logged In: YES 
user_id=80475

Barry, is this the intended behavior or should the comment 
in the docs be eliminated?  The conversation in 
www.python.org/sf/463330 was not clear to me on this point.

Confirmed:
>>> import base64
>>> v = base64.encodestring('hello!')
>>> w = base64.encodestring('hello!\n')
>>> v == w, v , w
(False, 'aGVsbG8h\n', 'aGVsbG8hCg==\n')

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470



From noreply@sourceforge.net  Wed May 15 17:32:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 09:32:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E1781hA-0008Pt-00@usw-sf-web3.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 10:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

----------------------------------------------------------------------

>Comment By: Graham Horler (grahamh)
Date: 2002-05-15 17:32

Message:
Logged In: YES 
user_id=543663

Thanks Michael, its all incredibly clear now (sorry Martin).

I think using arrays sounds a great idea.
IMVHO as to backward compatibility, AFAICT its not 
documented that arrays can be passed to ioctl() anyway (only 
says int and string no?), so it's only breaking undocumented 
behaviour.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-15 16:38

Message:
Logged In: YES 
user_id=6656

grahamh: I think Martin understood you fine.

Remember that arrays are mutable, whereas strings are not.

So the idea would be that you'd write

buf = array.array('c', '\000'*256)
ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf)

then the first "ret" bytes of "buf" would be valid.

However this possibly breaks backwards compatibility, as you
can already pass arrays into the ioctl function and they are
not modified.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 15:44

Message:
Logged In: YES 
user_id=543663

Re Loewis:
Not sure what you mean, perhaps an example of the 
problem from me would help:

In C:
    char buf[256], strbuf[256];
    int ret, fd;
    fd = open(...)
    ret = ioctl(fd, IOCTL_NUMBER, buf);
    strncpy(strbuf, buf, ret);

This is impossible with the current fcntl module:
    buf = "X" * struct.calcsize("256s")
    buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf)
    # The positive ioctl() return value is lost, and
    # hence I dont know how much of buf is significant

Extract from asm/unistd.h:

#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

So positive values are valid, but are being lost.

Anthony's patch looks good (thanks, I have not had a 
chance to test it myself yet), and the above example would 
be:
    buf = "X" * struct.calcsize("256s")
    ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf)
    strbuf = buf[:ret] # Result!

Now, to test my understanding of your last comment about 
array objects Loewis, do you mean:
- pass in a mutable list that gets changed in place to [ret, 
buf]
- return (ret, buf) if called like this: ioctl(fd, IOC, [buf])
- or something else - please give example.

Thanks people.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 13:04

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 13:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 11:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470



From noreply@sourceforge.net  Wed May 15 17:35:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 09:35:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-521706 ] Python expects __eprintf on Solaris
Message-ID: <E1781kC-0000jg-00@usw-sf-web4.sourceforge.net>

Bugs item #521706, was opened at 2002-02-23 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=521706&group_id=5470

Category: Build
Group: Python 2.1.2
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Greg Kochanski (gpk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python expects __eprintf on Solaris

Initial Comment:
ftp_up.py
Traceback (most recent call last):
  File "/usr/local/bin/ftp_up.py", line 10, in ?
    import ftplib
  File "/usr/local/lib/python2.1/ftplib.py", line 46,
in ?
    import socket
  File "/usr/local/lib/python2.1/socket.py", line 41,
in ?
    from _socket import *
ImportError: ld.so.1: /usr/local/bin/python: fatal:
relocation error: file
/usr/local/lib/python2.1/lib-dynload/_socket.so: symbol
__eprintf: referenced symbol not found


On Solaris 2.6 (current patches), Python 2.1.2
out-of-the-box install.

nm *.a | grep eprintf   shows nothing in /lib and
/usr/lib.  Presumably, the build system is expecting
that function to exist, when it really doesn't.

Same problem on Solaris 2.7:

/usr/local/bin/python
Python 2.1.2 (#1, Jan 23 2002, 10:44:53) [C] on sunos5
Type "copyright", "credits" or "license" for more
information.
>>> import _socket
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: ld.so.1: /usr/local/bin/python: fatal:
relocation error: file
/usr/local/lib/python2.1/lib-dynload/_socket.so: symbol
__eprintf: referenced symbol not found
>>> 


----------------------------------------------------------------------

Comment By: Wolfgang Kaltz (jwkaltz)
Date: 2002-05-15 18:35

Message:
Logged In: YES 
user_id=387111

> Are you certain that you have build all relevant objects
with the system compiler (including, for example, any
OpenSSL installation)?

I want to add a comment on that, because this was the only
useful suggestion I found on the Internet to help me solve a
similar problem. 
The issue is, under Solaris, if you have built gcc BEFORE
installing gnu binutils, be sure to recompile gcc entirely
afterwards, to that gcc itself is built with gnu ld.
Otherwise you will get strange effects like your "referenced
symbol not found".
To recompile gcc use the configure parameters --with-gnu-ld
and --with-gnu-as - otherwise it may use the Sun linker
anyway and your problem will remain.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:49

Message:
Logged In: YES 
user_id=21627

Closed for lack of feedback.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-24 00:09

Message:
Logged In: YES 
user_id=21627

This is not a bug in Python, but in your installation.
Python does not, in itself, ever call __eprintf. Instead,
certain versions of gcc emit references to this symbol when
expanding the assert macro. In turn, you need to link such
object files with libgcc.a.

Are you certain that you have build all relevant objects
with the system compiler (including, for example, any
OpenSSL installation)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=521706&group_id=5470



From noreply@sourceforge.net  Wed May 15 17:53:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 09:53:31 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-517371 ] Add .count() method to tuples
Message-ID: <E17821r-0001eT-00@usw-sf-web1.sourceforge.net>

Feature Requests item #517371, was opened at 2002-02-14 03:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=517371&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add .count() method to tuples

Initial Comment:
Tuples have every method afforded to lists except for 
those which mutate the list; however, there is one 
exception:  .count() appears to have been left out 
eventhough it can be well-defined for tuples as well 
as lists.

>>> s = 'the trump'
>>> s.count('t')
2
>>> list(s).count('t')
2
>>> tuple(s).count('t')
Traceback (most recent call last):
  File "<pyshell#12>", line 1, in ?
    tuple(s).count('t')
AttributeError: 'tuple' object has no attribute 'count'


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-03-27 05:24

Message:
Logged In: YES 
user_id=80475

IMHO, the forces pushing toward using lists versus tuples 
should be immutability and performance rather than the 
absence of methods.

Even if being pushed were a feature, a more important 
feature is substitutability -- the ability to develop a 
program using lists and then make a late design decision 
that tuples would have been a better choice.  

Substitutability is unnecessarily impaired by the absence 
of .index() and .count().

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-14 14:33

Message:
Logged In: YES 
user_id=31435

Guido has rejected this idea before, so don't hold your 
breath.  tuples and lists are intended to be used in 
different ways, and it's "a feature" that their differing 
methods push you toward using them as intended.

Note that tuples don't support .index() either, and that's 
also intentional.

Note that you can use the operator.countOf() function on 
tuples (and, in 2.2, on any iterable object).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=517371&group_id=5470



From noreply@sourceforge.net  Wed May 15 18:21:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 10:21:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E1782SU-00020U-00@usw-sf-web1.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 11:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 19:21

Message:
Logged In: YES 
user_id=21627

I would not be concerned about the backwards compatibility,
either: if anybody is passing arrays, there is a good chance
that the ioctl does not modify the buffer, or that the
caller would not worry about the (missing) modification - or
else we had seen reports before.

So documenting in Misc/NEWS and the documentation that
mutable  objects supporting the (write) buffer interface may
now mutate seems sufficient.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 18:32

Message:
Logged In: YES 
user_id=543663

Thanks Michael, its all incredibly clear now (sorry Martin).

I think using arrays sounds a great idea.
IMVHO as to backward compatibility, AFAICT its not 
documented that arrays can be passed to ioctl() anyway (only 
says int and string no?), so it's only breaking undocumented 
behaviour.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-15 17:38

Message:
Logged In: YES 
user_id=6656

grahamh: I think Martin understood you fine.

Remember that arrays are mutable, whereas strings are not.

So the idea would be that you'd write

buf = array.array('c', '\000'*256)
ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf)

then the first "ret" bytes of "buf" would be valid.

However this possibly breaks backwards compatibility, as you
can already pass arrays into the ioctl function and they are
not modified.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 16:44

Message:
Logged In: YES 
user_id=543663

Re Loewis:
Not sure what you mean, perhaps an example of the 
problem from me would help:

In C:
    char buf[256], strbuf[256];
    int ret, fd;
    fd = open(...)
    ret = ioctl(fd, IOCTL_NUMBER, buf);
    strncpy(strbuf, buf, ret);

This is impossible with the current fcntl module:
    buf = "X" * struct.calcsize("256s")
    buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf)
    # The positive ioctl() return value is lost, and
    # hence I dont know how much of buf is significant

Extract from asm/unistd.h:

#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

So positive values are valid, but are being lost.

Anthony's patch looks good (thanks, I have not had a 
chance to test it myself yet), and the above example would 
be:
    buf = "X" * struct.calcsize("256s")
    ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf)
    strbuf = buf[:ret] # Result!

Now, to test my understanding of your last comment about 
array objects Loewis, do you mean:
- pass in a mutable list that gets changed in place to [ret, 
buf]
- return (ret, buf) if called like this: ioctl(fd, IOC, [buf])
- or something else - please give example.

Thanks people.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 14:04

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 14:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 12:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470



From noreply@sourceforge.net  Wed May 15 18:24:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 10:24:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-556370 ] Expat improperly described in setup.py
Message-ID: <E1782Vy-0001Jb-00@usw-sf-web4.sourceforge.net>

Bugs item #556370, was opened at 2002-05-15 16:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556370&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Moshe Yudkowsky (myudkowsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expat improperly described in setup.py

Initial Comment:
This bug is for 2.2.1, not 2.2.1 "candidate."

Setup.py in the home directory explains how to obtain
the current version of the expat package. However, it
gives the path to the private home page of the original
developer. The package at that location is incorrect;
the correct package is at
<http://sourceforge.net/projects/expat/>.

The stale package introduces several problems:
* The package does not create the "expat.h" in
/usr/include that setup.py looks for
* The stale package does not automatically create libaries

The correct package fixes both of these problems.

SUGGESTED FIX:

* Modify setup.py to point to correct package. Note:
configure, make, make install will install the correct
libaries and include files.

* Modify README to include information about expat.
Speaking as a user, there's no reason for me to suspect
that I have to read setup.py to find out which modules
might not be included when I compile! Information about
expat belongs in README, so that I understand what
packages might be necessary for me to install before I
run the installation process.

HELP:

If you wish to assign me to rewrite this documentation,
I can do so; I'm a little reluctant to touch setup.py
because I only have a Linux setup here, and touching
any py module means testing across builds IMHO.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 19:24

Message:
Logged In: YES 
user_id=21627

I would appreciate if you could produce a patch (context
diff, please), both for setup.py, and Modules/Setup.

I don't think modifying README is necessary, since the
reader is already directed to read Modules/Setup in README.
If you would like to see specific text, feel free to include
it in your patch.

Please attach the patch to this report.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556370&group_id=5470



From noreply@sourceforge.net  Wed May 15 21:52:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 13:52:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-555404 ] bug in utils.py (not allow "" pathname)
Message-ID: <E1785kg-0002xg-00@usw-sf-web3.sourceforge.net>

Bugs item #555404, was opened at 2002-05-13 08:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555404&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Evgeny Cherkashin (eugeneai)
Assigned to: Nobody/Anonymous (nobody)
>Summary: bug in utils.py (not allow "" pathname)

Initial Comment:
According to documentation : "If You want to place a
data file in Python root directory You should use "" as
a path name". But in this case exception raised due to
check pathname[0]=='/'

Just add a line marked by "+".

in convert_path method

     if os.sep == '/':
         return pathname
+    if pathname == '': return
     if pathname[0] == '/':
         raise ValueError, "path '%s' cannot be
absolute" % pathname
     if pathname[-1] == '/':
         raise ValueError, "path '%s' cannot end with
'/'" % pathname


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-05-15 16:52

Message:
Logged In: YES 
user_id=11375

Fixed in rev. 1.67 of distutils/util.py.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555404&group_id=5470



From noreply@sourceforge.net  Wed May 15 21:54:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 13:54:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-550364 ] Version number handling
Message-ID: <E1785nP-0002zI-00@usw-sf-web3.sourceforge.net>

Bugs item #550364, was opened at 2002-04-29 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550364&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: Version number handling

Initial Comment:
A while ago, Tim Peters mentioned in a check-in message:

"Change the version string from "2.2+" to "2.3a0".  distutils 
peels off
the first 3 characters of this string in several places, so for as 
long
as they remain "2.2" it confuses the heck out of attempts to 
build 2.3 stuff using distutils."

It's true; distutils does sys.version[:3] in a few places.
The attached patch factors this out so it'll be easier to 
change.  

(There's also a Python development issue here, namely when
the version number gets bumped in the CVS tree.)


 


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-05-15 16:54

Message:
Logged In: YES 
user_id=11375

Maybe.  But I don't know if I still care about 1.5.2.  If 
I don't, then the code can just always use sys.version_info.



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 06:51

Message:
Logged In: YES 
user_id=80475

Nice factoring.

Would it be more bulletproof to use sys.version_info 
instead of sys.version[:3]?  Perhaps, wrap it in try/except 
to catch versions before Py2.0.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550364&group_id=5470



From noreply@sourceforge.net  Wed May 15 21:50:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 13:50:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-555900 ] telnetlib: UnboundLocalError
Message-ID: <E1785jI-0002td-00@usw-sf-web2.sourceforge.net>

Bugs item #555900, was opened at 2002-05-14 08:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555900&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeroen Vloothuis (slmm)
Assigned to: Nobody/Anonymous (nobody)
Summary: telnetlib: UnboundLocalError

Initial Comment:
When i run my script i get this:

Traceback (most recent call last):
  File "./zis.py", line 13, in ?
    tn.read_until("Usernummer : ")
  File "/usr/lib/python2.2/telnetlib.py", line 297, in
read_until
    self.process_rawq()
  File "/usr/lib/python2.2/telnetlib.py", line 424, in
process_rawq
    self.msg('IAC %d not recognized' % ord(opt))
UnboundLocalError: local variable 'opt' referenced
before assignment

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-05-15 16:50

Message:
Logged In: YES 
user_id=11375

Fixed in current CVS (rev. 1.18 of telnetlib.py).
Duplicate of bug 554073.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555900&group_id=5470



From noreply@sourceforge.net  Wed May 15 22:06:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 14:06:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-542912 ] Distutils readme outdated
Message-ID: <E1785yU-00037t-00@usw-sf-web3.sourceforge.net>

Bugs item #542912, was opened at 2002-04-12 05:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542912&group_id=5470

Category: Distutils
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Greg Ward (gward)
Summary: Distutils readme outdated

Initial Comment:
The distutils readme file is outdated. It says the documentation isn't part of the standard python docs (it is, nowadays) and points you to the SIG page, where you find outdated documentation.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-05-15 17:06

Message:
Logged In: YES 
user_id=11375

I've updated the README to point to the current docs on 
python.org, and to request bugs/patches through SF, not via 
e-mail to Greg.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542912&group_id=5470



From noreply@sourceforge.net  Wed May 15 23:50:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 15:50:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E1787bU-0004C2-00@usw-sf-web2.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 10:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

----------------------------------------------------------------------

>Comment By: Graham Horler (grahamh)
Date: 2002-05-15 23:50

Message:
Logged In: YES 
user_id=543663

I just realised - using array objects and changing in-place 
oversomes the arbitrary limit of 1024 bytes.  We could then 
achieve the full 16384 byte nirvana - hurrah!


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 18:21

Message:
Logged In: YES 
user_id=21627

I would not be concerned about the backwards compatibility,
either: if anybody is passing arrays, there is a good chance
that the ioctl does not modify the buffer, or that the
caller would not worry about the (missing) modification - or
else we had seen reports before.

So documenting in Misc/NEWS and the documentation that
mutable  objects supporting the (write) buffer interface may
now mutate seems sufficient.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 17:32

Message:
Logged In: YES 
user_id=543663

Thanks Michael, its all incredibly clear now (sorry Martin).

I think using arrays sounds a great idea.
IMVHO as to backward compatibility, AFAICT its not 
documented that arrays can be passed to ioctl() anyway (only 
says int and string no?), so it's only breaking undocumented 
behaviour.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-15 16:38

Message:
Logged In: YES 
user_id=6656

grahamh: I think Martin understood you fine.

Remember that arrays are mutable, whereas strings are not.

So the idea would be that you'd write

buf = array.array('c', '\000'*256)
ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf)

then the first "ret" bytes of "buf" would be valid.

However this possibly breaks backwards compatibility, as you
can already pass arrays into the ioctl function and they are
not modified.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 15:44

Message:
Logged In: YES 
user_id=543663

Re Loewis:
Not sure what you mean, perhaps an example of the 
problem from me would help:

In C:
    char buf[256], strbuf[256];
    int ret, fd;
    fd = open(...)
    ret = ioctl(fd, IOCTL_NUMBER, buf);
    strncpy(strbuf, buf, ret);

This is impossible with the current fcntl module:
    buf = "X" * struct.calcsize("256s")
    buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf)
    # The positive ioctl() return value is lost, and
    # hence I dont know how much of buf is significant

Extract from asm/unistd.h:

#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

So positive values are valid, but are being lost.

Anthony's patch looks good (thanks, I have not had a 
chance to test it myself yet), and the above example would 
be:
    buf = "X" * struct.calcsize("256s")
    ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf)
    strbuf = buf[:ret] # Result!

Now, to test my understanding of your last comment about 
array objects Loewis, do you mean:
- pass in a mutable list that gets changed in place to [ret, 
buf]
- return (ret, buf) if called like this: ioctl(fd, IOC, [buf])
- or something else - please give example.

Thanks people.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 13:04

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 13:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 11:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470



From noreply@sourceforge.net  Thu May 16 02:02:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 18:02:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-408271 ] crash in shelve module
Message-ID: <E1789et-0005YO-00@usw-sf-web2.sourceforge.net>

Bugs item #408271, was opened at 2001-03-13 10:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: crash in shelve module

Initial Comment:
While using shelve module on SGI
sloth 271> uname -a
IRIX64 sloth 6.5 04191225 IP27

my python program crashes and
I am getting following error message:

  File "/usr/local/lib/python1.5/shelve.py", line 71,
in __setitem__
    self.dict[key] = f.getvalue()
bsddb.error: (0, 'Error')

At the time the size of the "shelve" file was quite big
(maybe this is a problem ?)
sloth 267> ls -lt *shelve
-rw-r--r--    1 ryszard  cdiApps   85778432 Mar 13
12:27 recap_mddr.shelve


----------------------------------------------------------------------

Comment By: Martin D Katz, Ph.D. (drbits)
Date: 2002-05-15 18:02

Message:
Logged In: YES 
user_id=276840

Apparently, this problem only occurs when the hash table 
form of bsddb is used. The b-bree version (btopen) does not 
have this problem.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-06 20:56

Message:
Logged In: YES 
user_id=29957

Barry, if it's known to be stuffed, why is it
still there?
Is there an open bug report for how it's busted?
A bunch of stuff that depends on getting "a db
storage" is going to use bsddb...


----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 20:49

Message:
Logged In: YES 
user_id=59803

Submitted patch #553108.

----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 19:35

Message:
Logged In: YES 
user_id=59803

If bssdb is broken, shelve should use anydbm and bsddb 
should be deprecated. Precedence: regexp.

ActivePython 2.2.0 Build 221 (ActiveState Corp.) based on
Python 2.2 (#28, Mar 28 2002, 12:10:20) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import shelve
>>> s = shelve.open('temp.db', 'c')
>>> s.dict
<bsddb.bsddb object at 0x008A2D48>

Python 2.2.1 (#1, Apr 30 2002, 17:02:05)
[GCC 2.95.3 20010315 (SuSE)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import shelve
>>> s = shelve.open('temp.db', 'c')
>>> s.dict
<bsddb.bsddb object at 0x815a388>
>>>



----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-06 08:13

Message:
Logged In: YES 
user_id=12800

I'd highly suggest that any serious work with BerkeleyDB be
done with pybsddb and a more modern version of Berkeley. 
The bsddb module that comes with Python 2.2 has serious
problems, including not being able to link on some *nix
distros.  Also BDB 1.85 is way way old and has many known
problems. 

I ran the deadlybloddyserious example using BDB 3.11 and
pybsddb 3.0 and it passed with flying colors.  See
www.sleepycat.com for the latest BDB's and pybsddb.sf.net
for the latest Python wrappers.

----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 00:55

Message:
Logged In: YES 
user_id=59803

You might want to re-open this one, Barry. The problem 
seems to be with any large number of bsddb inserts, which 
can also be triggered by shelve. See: 

http://www.deadlybloodyserious.com/Python/2002/05/06.html

http://bugs.activestate.com/show_bug.cgi?id=10242 

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-03-18 08:10

Message:
Logged In: YES 
user_id=12800

Besides, this was submitted by "anonymous" and the only clue
to the identity of the original poster is in the ls output. 
Unfortunately, I'm not prepared to spam all the Ryszard's in
my name database. :)

I'm closing this report until/unless we get more
information.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:03

Message:
Logged In: YES 
user_id=31435

Assigned to Barry because there's not enough info here to 
do anything about it <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470



From noreply@sourceforge.net  Thu May 16 02:09:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 18:09:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-408271 ] crash in shelve module
Message-ID: <E1789m6-0006SH-00@usw-sf-web4.sourceforge.net>

Bugs item #408271, was opened at 2001-03-13 10:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: crash in shelve module

Initial Comment:
While using shelve module on SGI
sloth 271> uname -a
IRIX64 sloth 6.5 04191225 IP27

my python program crashes and
I am getting following error message:

  File "/usr/local/lib/python1.5/shelve.py", line 71,
in __setitem__
    self.dict[key] = f.getvalue()
bsddb.error: (0, 'Error')

At the time the size of the "shelve" file was quite big
(maybe this is a problem ?)
sloth 267> ls -lt *shelve
-rw-r--r--    1 ryszard  cdiApps   85778432 Mar 13
12:27 recap_mddr.shelve


----------------------------------------------------------------------

Comment By: Martin D Katz, Ph.D. (drbits)
Date: 2002-05-15 18:09

Message:
Logged In: YES 
user_id=276840

Apparently, this problem only occurs when the hash table 
form of bsddb is used. The b-bree version (btopen) does not 
have this problem.

----------------------------------------------------------------------

Comment By: Martin D Katz, Ph.D. (drbits)
Date: 2002-05-15 18:02

Message:
Logged In: YES 
user_id=276840

Apparently, this problem only occurs when the hash table 
form of bsddb is used. The b-bree version (btopen) does not 
have this problem.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-06 20:56

Message:
Logged In: YES 
user_id=29957

Barry, if it's known to be stuffed, why is it
still there?
Is there an open bug report for how it's busted?
A bunch of stuff that depends on getting "a db
storage" is going to use bsddb...


----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 20:49

Message:
Logged In: YES 
user_id=59803

Submitted patch #553108.

----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 19:35

Message:
Logged In: YES 
user_id=59803

If bssdb is broken, shelve should use anydbm and bsddb 
should be deprecated. Precedence: regexp.

ActivePython 2.2.0 Build 221 (ActiveState Corp.) based on
Python 2.2 (#28, Mar 28 2002, 12:10:20) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import shelve
>>> s = shelve.open('temp.db', 'c')
>>> s.dict
<bsddb.bsddb object at 0x008A2D48>

Python 2.2.1 (#1, Apr 30 2002, 17:02:05)
[GCC 2.95.3 20010315 (SuSE)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import shelve
>>> s = shelve.open('temp.db', 'c')
>>> s.dict
<bsddb.bsddb object at 0x815a388>
>>>



----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-06 08:13

Message:
Logged In: YES 
user_id=12800

I'd highly suggest that any serious work with BerkeleyDB be
done with pybsddb and a more modern version of Berkeley. 
The bsddb module that comes with Python 2.2 has serious
problems, including not being able to link on some *nix
distros.  Also BDB 1.85 is way way old and has many known
problems. 

I ran the deadlybloddyserious example using BDB 3.11 and
pybsddb 3.0 and it passed with flying colors.  See
www.sleepycat.com for the latest BDB's and pybsddb.sf.net
for the latest Python wrappers.

----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 00:55

Message:
Logged In: YES 
user_id=59803

You might want to re-open this one, Barry. The problem 
seems to be with any large number of bsddb inserts, which 
can also be triggered by shelve. See: 

http://www.deadlybloodyserious.com/Python/2002/05/06.html

http://bugs.activestate.com/show_bug.cgi?id=10242 

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-03-18 08:10

Message:
Logged In: YES 
user_id=12800

Besides, this was submitted by "anonymous" and the only clue
to the identity of the original poster is in the ls output. 
Unfortunately, I'm not prepared to spam all the Ryszard's in
my name database. :)

I'm closing this report until/unless we get more
information.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:03

Message:
Logged In: YES 
user_id=31435

Assigned to Barry because there's not enough info here to 
do anything about it <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470



From noreply@sourceforge.net  Thu May 16 04:14:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 20:14:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-533291 ] __reduce__ does not work as documented
Message-ID: <E178BjA-00074H-00@usw-sf-web3.sourceforge.net>

Bugs item #533291, was opened at 2002-03-21 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: __reduce__ does not work as documented

Initial Comment:
The documentation for __reduce__ says that the second
element of the returned tuple can either be a tuple
of arguments or None.  The copy module does not handle
the None case:

  class C(object):
    def __reduce__(self):
        return (C, None)

  import copy
  copy.copy(C())



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 22:14

Message:
Logged In: YES 
user_id=80475

See attached documentation and code patch for deprecating 
the None version.  If approved, re-assign to Raymond for 
commit.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:36

Message:
Logged In: YES 
user_id=6380

So be it.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 12:09

Message:
Logged In: YES 
user_id=35752

I would prefer that the None version be deprecated.  The
documentation for __reduce__ is confusing enough as it is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 11:59

Message:
Logged In: YES 
user_id=6380

I'm not sure it's that simple. While pickling a C instance
indeed succeed, unpickling it raises a strange exception:

>>> pickle.loads(pickle.dumps(C()))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/guido/trunk/Lib/pickle.py", line 982, in loads
    return Unpickler(file).load()
  File "/home/guido/trunk/Lib/pickle.py", line 593, in load
    dispatch[key](self)
  File "/home/guido/trunk/Lib/pickle.py", line 842, in
load_reduce
    value = callable.__basicnew__()
AttributeError: type object 'C' has no attribute
'__basicnew__'
>>>

It appears that an argument tuple of None signals some
special Jim-Fulton-only behavior. __basicnew__ is a feature
of ExtensionClasses (similar to __new__ in Python 2.2), and
while ExtensionClasses work in 2.2, they're being
deprecated: Zope 2.x will continue to use Python 2.1.x, and
Zope 3 will require Python 2.2 or higher.

The copy module has never worked for ExtensionClass
instances (unless maybe the class defines a __copy__
method).

Maybe the right thing to do is to document 'None' as a
special case that one shouldn't use, and deprecate
__basicnew__?

(Hm, OTOH why don't I just approve your fix so we can stop
thinking about this. :-)

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 10:10

Message:
Logged In: YES 
user_id=35752

Added trivial patch to fix copy.py module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470



From noreply@sourceforge.net  Thu May 16 05:10:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 21:10:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-532467 ] 6.9 The raise statement is confusing
Message-ID: <E178Cav-0008Cq-00@usw-sf-web4.sourceforge.net>

Bugs item #532467, was opened at 2002-03-20 08:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick K. O'Brien (pobrien)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 6.9 The raise statement is confusing

Initial Comment:
The description supplied for "6.9 The raise statement" 
is confusing. In particular, it starts by explaining 
the intent of each "expresssion" and midway switches 
to "object" instead of expression. In particular, I 
can't make heads or tails out of the following passage:

"If the first object is a string, it then raises the 
exception identified by the first object, with the 
second one (or None) as its parameter. If the first 
object is a class or instance, it raises the exception 
identified by the class of the instance determined in 
the previous step, with the instance as its parameter."

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 23:10

Message:
Logged In: YES 
user_id=80475

Attached two alternative patches.

The first makes minimal changes to achieve a clear and 
consistent use of "objects" versus "expressions".

The second alternative re-paragraphs the text and uses 
parallel sentence contruction to provide (IMHO) 
greater clarity without getting a headache reading it.

If accepted, please re-assign to Raymond for a commit to 
2.3 and to release22-maint.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470



From noreply@sourceforge.net  Thu May 16 05:32:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 21:32:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-408271 ] crash in shelve module
Message-ID: <E178Cvw-0007Zx-00@usw-sf-web2.sourceforge.net>

Bugs item #408271, was opened at 2001-03-13 13:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470

Category: Python Library
Group: None
>Status: Open
Resolution: Wont Fix
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: crash in shelve module

Initial Comment:
While using shelve module on SGI
sloth 271> uname -a
IRIX64 sloth 6.5 04191225 IP27

my python program crashes and
I am getting following error message:

  File "/usr/local/lib/python1.5/shelve.py", line 71,
in __setitem__
    self.dict[key] = f.getvalue()
bsddb.error: (0, 'Error')

At the time the size of the "shelve" file was quite big
(maybe this is a problem ?)
sloth 267> ls -lt *shelve
-rw-r--r--    1 ryszard  cdiApps   85778432 Mar 13
12:27 recap_mddr.shelve


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-16 00:32

Message:
Logged In: YES 
user_id=12800

I'll re-open this one as a reminder to myself to deal with
this somehow.  All I know is that distutils build of
bsddbmodule fails for all the Linux flavors I've tested it
on.  I think the autodetection of the library to link
against is busted in Py2.2 & 2.3.  I don't have time to
think more about this now, but I will make sure I do
/something/ about it for Py2.3.

----------------------------------------------------------------------

Comment By: Martin D Katz, Ph.D. (drbits)
Date: 2002-05-15 21:09

Message:
Logged In: YES 
user_id=276840

Apparently, this problem only occurs when the hash table 
form of bsddb is used. The b-bree version (btopen) does not 
have this problem.

----------------------------------------------------------------------

Comment By: Martin D Katz, Ph.D. (drbits)
Date: 2002-05-15 21:02

Message:
Logged In: YES 
user_id=276840

Apparently, this problem only occurs when the hash table 
form of bsddb is used. The b-bree version (btopen) does not 
have this problem.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-06 23:56

Message:
Logged In: YES 
user_id=29957

Barry, if it's known to be stuffed, why is it
still there?
Is there an open bug report for how it's busted?
A bunch of stuff that depends on getting "a db
storage" is going to use bsddb...


----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 23:49

Message:
Logged In: YES 
user_id=59803

Submitted patch #553108.

----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 22:35

Message:
Logged In: YES 
user_id=59803

If bssdb is broken, shelve should use anydbm and bsddb 
should be deprecated. Precedence: regexp.

ActivePython 2.2.0 Build 221 (ActiveState Corp.) based on
Python 2.2 (#28, Mar 28 2002, 12:10:20) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import shelve
>>> s = shelve.open('temp.db', 'c')
>>> s.dict
<bsddb.bsddb object at 0x008A2D48>

Python 2.2.1 (#1, Apr 30 2002, 17:02:05)
[GCC 2.95.3 20010315 (SuSE)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import shelve
>>> s = shelve.open('temp.db', 'c')
>>> s.dict
<bsddb.bsddb object at 0x815a388>
>>>



----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-06 11:13

Message:
Logged In: YES 
user_id=12800

I'd highly suggest that any serious work with BerkeleyDB be
done with pybsddb and a more modern version of Berkeley. 
The bsddb module that comes with Python 2.2 has serious
problems, including not being able to link on some *nix
distros.  Also BDB 1.85 is way way old and has many known
problems. 

I ran the deadlybloddyserious example using BDB 3.11 and
pybsddb 3.0 and it passed with flying colors.  See
www.sleepycat.com for the latest BDB's and pybsddb.sf.net
for the latest Python wrappers.

----------------------------------------------------------------------

Comment By: Garth T Kidd (gtk)
Date: 2002-05-06 03:55

Message:
Logged In: YES 
user_id=59803

You might want to re-open this one, Barry. The problem 
seems to be with any large number of bsddb inserts, which 
can also be triggered by shelve. See: 

http://www.deadlybloodyserious.com/Python/2002/05/06.html

http://bugs.activestate.com/show_bug.cgi?id=10242 

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-03-18 11:10

Message:
Logged In: YES 
user_id=12800

Besides, this was submitted by "anonymous" and the only clue
to the identity of the original poster is in the ls output. 
Unfortunately, I'm not prepared to spam all the Ryszard's in
my name database. :)

I'm closing this report until/unless we get more
information.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-18 01:03

Message:
Logged In: YES 
user_id=31435

Assigned to Barry because there's not enough info here to 
do anything about it <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=408271&group_id=5470



From noreply@sourceforge.net  Thu May 16 05:39:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 May 2002 21:39:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E178D33-0007e5-00@usw-sf-web2.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 06:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Paul Rouse (p_rouse)
Assigned to: Raymond Hettinger (rhettinger)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 23:39

Message:
Logged In: YES 
user_id=80475

Committed as libbase64.tex 1.21 and 1.20.6.1.
Closing bug.


----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-15 11:28

Message:
Logged In: YES 
user_id=12800

Fred's right, the behavior is long standing.  I'm good with
the patch.  Reassigning to Raymond for application of patch,
who should close this report once that's done.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-15 10:06

Message:
Logged In: YES 
user_id=3066

I think the patch should apply to both release21-maint and
release22-maint as well as the trunk.  I don't think this
describes a recently introduced behavior in the base64 module.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 09:57

Message:
Logged In: YES 
user_id=80475

Inserted new wording into patch below.
Do you also want this backported to release22-maint?



----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-15 08:57

Message:
Logged In: YES 
user_id=12800

Actually, I realized encodestring() is a bit more subtle
than that.  I think what it actually does is "return a
string containing one or more lines of base64-encoded data"
always including an extra trailing newline.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 03:13

Message:
Logged In: YES 
user_id=80475

Please approve the new patch.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 23:51

Message:
Logged In: YES 
user_id=12800

I'm not sure the patch is sufficient.  You need to at least
explain that a newline is always added to the output.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-14 21:40

Message:
Logged In: YES 
user_id=3066

Barry, you're the MIME guru, tell Raymond whether he should
check in his patch.  ;-)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 11:11

Message:
Logged In: YES 
user_id=80475

Fred, is the attached patch okay to commit to 2.3 and 
release 22-maint?

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-14 08:52

Message:
Logged In: YES 
user_id=12800

The intended behavior is irrelevant <wink>.  Since this is
how the base64 module works, it needs to be correctly
documented.  It's way too late to be changing this behavior,
as broken as some might think it is.:)

Note that the email package has an RFC 2045-2047 compliant
base64 encoding module called email.base64MIME.  It
currently isn't documented (but will be before 2.3 is released).

Reassigning to Fred so he can correct the base64 documentation.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 02:40

Message:
Logged In: YES 
user_id=80475

Barry, is this the intended behavior or should the comment 
in the docs be eliminated?  The conversation in 
www.python.org/sf/463330 was not clear to me on this point.

Confirmed:
>>> import base64
>>> v = base64.encodestring('hello!')
>>> w = base64.encodestring('hello!\n')
>>> v == w, v , w
(False, 'aGVsbG8h\n', 'aGVsbG8hCg==\n')

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470



From noreply@sourceforge.net  Thu May 16 10:21:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 02:21:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E178HSC-0003zu-00@usw-sf-web1.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 09:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-05-16 09:21

Message:
Logged In: YES 
user_id=6656

I'm not *trying* to be a party-pooper, but there's another
problem: the point of passing a mutable array is so that
fcntl.ioctl can return ioctl(2)'s return code rather than
the string it returns now.  So if someone does use arrays
(or I guess Numeric.arrays?) for ioctls this would very
likely cause breakage.  I don't know how likely that is. 
Probably not very.  But I know that if this change broke my
code, I'd be a bit miffed.

All this is a bit annoying, as mutating arrays is clearly
the right solution -- where's that time machine?

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 22:50

Message:
Logged In: YES 
user_id=543663

I just realised - using array objects and changing in-place 
oversomes the arbitrary limit of 1024 bytes.  We could then 
achieve the full 16384 byte nirvana - hurrah!


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 17:21

Message:
Logged In: YES 
user_id=21627

I would not be concerned about the backwards compatibility,
either: if anybody is passing arrays, there is a good chance
that the ioctl does not modify the buffer, or that the
caller would not worry about the (missing) modification - or
else we had seen reports before.

So documenting in Misc/NEWS and the documentation that
mutable  objects supporting the (write) buffer interface may
now mutate seems sufficient.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 16:32

Message:
Logged In: YES 
user_id=543663

Thanks Michael, its all incredibly clear now (sorry Martin).

I think using arrays sounds a great idea.
IMVHO as to backward compatibility, AFAICT its not 
documented that arrays can be passed to ioctl() anyway (only 
says int and string no?), so it's only breaking undocumented 
behaviour.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-15 15:38

Message:
Logged In: YES 
user_id=6656

grahamh: I think Martin understood you fine.

Remember that arrays are mutable, whereas strings are not.

So the idea would be that you'd write

buf = array.array('c', '\000'*256)
ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf)

then the first "ret" bytes of "buf" would be valid.

However this possibly breaks backwards compatibility, as you
can already pass arrays into the ioctl function and they are
not modified.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 14:44

Message:
Logged In: YES 
user_id=543663

Re Loewis:
Not sure what you mean, perhaps an example of the 
problem from me would help:

In C:
    char buf[256], strbuf[256];
    int ret, fd;
    fd = open(...)
    ret = ioctl(fd, IOCTL_NUMBER, buf);
    strncpy(strbuf, buf, ret);

This is impossible with the current fcntl module:
    buf = "X" * struct.calcsize("256s")
    buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf)
    # The positive ioctl() return value is lost, and
    # hence I dont know how much of buf is significant

Extract from asm/unistd.h:

#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

So positive values are valid, but are being lost.

Anthony's patch looks good (thanks, I have not had a 
chance to test it myself yet), and the above example would 
be:
    buf = "X" * struct.calcsize("256s")
    ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf)
    strbuf = buf[:ret] # Result!

Now, to test my understanding of your last comment about 
array objects Loewis, do you mean:
- pass in a mutable list that gets changed in place to [ret, 
buf]
- return (ret, buf) if called like this: ioctl(fd, IOC, [buf])
- or something else - please give example.

Thanks people.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 12:04

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 12:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 10:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470



From noreply@sourceforge.net  Thu May 16 11:34:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 03:34:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E178IaL-0002zk-00@usw-sf-web2.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 19:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-16 20:34

Message:
Logged In: YES 
user_id=29957

Hm. The solaris /proc lib I did in python, I used 'struct'
to dismantle C structures, but I did consider using byte
arrays. So that's one data point. 
(ok, it's not ioctls, but it's similar sort of data).
I'm loathe to go down the 'argument is mutable' optional
flag, but I really would prefer to make this work rather
than the ioctl2() approach, which really ain't that nice.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 19:21

Message:
Logged In: YES 
user_id=6656

I'm not *trying* to be a party-pooper, but there's another
problem: the point of passing a mutable array is so that
fcntl.ioctl can return ioctl(2)'s return code rather than
the string it returns now.  So if someone does use arrays
(or I guess Numeric.arrays?) for ioctls this would very
likely cause breakage.  I don't know how likely that is. 
Probably not very.  But I know that if this change broke my
code, I'd be a bit miffed.

All this is a bit annoying, as mutating arrays is clearly
the right solution -- where's that time machine?

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-16 08:50

Message:
Logged In: YES 
user_id=543663

I just realised - using array objects and changing in-place 
oversomes the arbitrary limit of 1024 bytes.  We could then 
achieve the full 16384 byte nirvana - hurrah!


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-16 03:21

Message:
Logged In: YES 
user_id=21627

I would not be concerned about the backwards compatibility,
either: if anybody is passing arrays, there is a good chance
that the ioctl does not modify the buffer, or that the
caller would not worry about the (missing) modification - or
else we had seen reports before.

So documenting in Misc/NEWS and the documentation that
mutable  objects supporting the (write) buffer interface may
now mutate seems sufficient.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-16 02:32

Message:
Logged In: YES 
user_id=543663

Thanks Michael, its all incredibly clear now (sorry Martin).

I think using arrays sounds a great idea.
IMVHO as to backward compatibility, AFAICT its not 
documented that arrays can be passed to ioctl() anyway (only 
says int and string no?), so it's only breaking undocumented 
behaviour.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 01:38

Message:
Logged In: YES 
user_id=6656

grahamh: I think Martin understood you fine.

Remember that arrays are mutable, whereas strings are not.

So the idea would be that you'd write

buf = array.array('c', '\000'*256)
ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf)

then the first "ret" bytes of "buf" would be valid.

However this possibly breaks backwards compatibility, as you
can already pass arrays into the ioctl function and they are
not modified.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-16 00:44

Message:
Logged In: YES 
user_id=543663

Re Loewis:
Not sure what you mean, perhaps an example of the 
problem from me would help:

In C:
    char buf[256], strbuf[256];
    int ret, fd;
    fd = open(...)
    ret = ioctl(fd, IOCTL_NUMBER, buf);
    strncpy(strbuf, buf, ret);

This is impossible with the current fcntl module:
    buf = "X" * struct.calcsize("256s")
    buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf)
    # The positive ioctl() return value is lost, and
    # hence I dont know how much of buf is significant

Extract from asm/unistd.h:

#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

So positive values are valid, but are being lost.

Anthony's patch looks good (thanks, I have not had a 
chance to test it myself yet), and the above example would 
be:
    buf = "X" * struct.calcsize("256s")
    ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf)
    strbuf = buf[:ret] # Result!

Now, to test my understanding of your last comment about 
array objects Loewis, do you mean:
- pass in a mutable list that gets changed in place to [ret, 
buf]
- return (ret, buf) if called like this: ioctl(fd, IOC, [buf])
- or something else - please give example.

Thanks people.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 22:04

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 22:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 20:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470



From noreply@sourceforge.net  Thu May 16 11:39:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 03:39:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-556121 ] Assertion failed (eval_code2)
Message-ID: <E178IfH-00032j-00@usw-sf-web2.sourceforge.net>

Bugs item #556121, was opened at 2002-05-15 07:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556121&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Stuart (rstuart)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion failed (eval_code2)

Initial Comment:
This has already been described in bug 499788:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470

That bug is closed.  The version mentioned in that bug is 2.1.2, and I guess they were hoping it 
went away in 2.1.3.  I am using 2.1.3 and still have the problem.

The problem
-----------
I have a fresh install of Zope.  In Zope I open the Tutorial.  It fails and this error appears in 
/var/log/zope:

python2.1: Python/ceval.c:695: eval_code2: Assertion `(stack_pointer - f->f_valuestack) 
<=f->f_stacksize' failed.

Software versions
-----------------
Distribution: RedHat 7.2
http://www.python.org/ftp/python/2.1.3/rpms/rh7.2/python2.1-2.1.3-1.i386.rpm
http://www.python.org/ftp/python/2.1.3/rpms/rh7.2/python2.1-devel-2.1.3-1.i386.rpm
http://www.taupro.com/static/RPMs/Zope-2.4.3-1.i386.rpm
http://www.taupro.com/static/RPMs/Zope-pcgi-2.4.3-1.i386.rpm

I also have Python 1.5.2 and Python 2.2 installed, but Zope should not be using them.



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-16 20:39

Message:
Logged In: YES 
user_id=29957

What version of Zope are you using? If you're not using
2.4.4 or 2.5.1, then you'll need to upgrade - versions 
earlier than trigger this horror. Or you can downgrade to 
python 2.1.1 and get silent memory corruption instead of
asserts :)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556121&group_id=5470



From noreply@sourceforge.net  Thu May 16 11:39:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 03:39:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-556121 ] Assertion failed (eval_code2)
Message-ID: <E178Ifc-00032z-00@usw-sf-web2.sourceforge.net>

Bugs item #556121, was opened at 2002-05-15 07:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556121&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Stuart (rstuart)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: Assertion failed (eval_code2)

Initial Comment:
This has already been described in bug 499788:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470

That bug is closed.  The version mentioned in that bug is 2.1.2, and I guess they were hoping it 
went away in 2.1.3.  I am using 2.1.3 and still have the problem.

The problem
-----------
I have a fresh install of Zope.  In Zope I open the Tutorial.  It fails and this error appears in 
/var/log/zope:

python2.1: Python/ceval.c:695: eval_code2: Assertion `(stack_pointer - f->f_valuestack) 
<=f->f_stacksize' failed.

Software versions
-----------------
Distribution: RedHat 7.2
http://www.python.org/ftp/python/2.1.3/rpms/rh7.2/python2.1-2.1.3-1.i386.rpm
http://www.python.org/ftp/python/2.1.3/rpms/rh7.2/python2.1-devel-2.1.3-1.i386.rpm
http://www.taupro.com/static/RPMs/Zope-2.4.3-1.i386.rpm
http://www.taupro.com/static/RPMs/Zope-pcgi-2.4.3-1.i386.rpm

I also have Python 1.5.2 and Python 2.2 installed, but Zope should not be using them.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-16 20:39

Message:
Logged In: YES 
user_id=29957

What version of Zope are you using? If you're not using
2.4.4 or 2.5.1, then you'll need to upgrade - versions 
earlier than trigger this horror. Or you can downgrade to 
python 2.1.1 and get silent memory corruption instead of
asserts :)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556121&group_id=5470



From noreply@sourceforge.net  Thu May 16 11:41:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 03:41:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-556121 ] Assertion failed (eval_code2)
Message-ID: <E178Igv-000340-00@usw-sf-web2.sourceforge.net>

Bugs item #556121, was opened at 2002-05-15 07:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556121&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Russell Stuart (rstuart)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Assertion failed (eval_code2)

Initial Comment:
This has already been described in bug 499788:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499788&group_id=5470

That bug is closed.  The version mentioned in that bug is 2.1.2, and I guess they were hoping it 
went away in 2.1.3.  I am using 2.1.3 and still have the problem.

The problem
-----------
I have a fresh install of Zope.  In Zope I open the Tutorial.  It fails and this error appears in 
/var/log/zope:

python2.1: Python/ceval.c:695: eval_code2: Assertion `(stack_pointer - f->f_valuestack) 
<=f->f_stacksize' failed.

Software versions
-----------------
Distribution: RedHat 7.2
http://www.python.org/ftp/python/2.1.3/rpms/rh7.2/python2.1-2.1.3-1.i386.rpm
http://www.python.org/ftp/python/2.1.3/rpms/rh7.2/python2.1-devel-2.1.3-1.i386.rpm
http://www.taupro.com/static/RPMs/Zope-2.4.3-1.i386.rpm
http://www.taupro.com/static/RPMs/Zope-pcgi-2.4.3-1.i386.rpm

I also have Python 1.5.2 and Python 2.2 installed, but Zope should not be using them.



----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-16 20:41

Message:
Logged In: YES 
user_id=29957

I just re-read your message, I missed the 'Zope 2.4.3'
bit. You'll need to upgrade to 2.4.4. This is a known
bug in 2.4.3.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-16 20:39

Message:
Logged In: YES 
user_id=29957

What version of Zope are you using? If you're not using
2.4.4 or 2.5.1, then you'll need to upgrade - versions 
earlier than trigger this horror. Or you can downgrade to 
python 2.1.1 and get silent memory corruption instead of
asserts :)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556121&group_id=5470



From noreply@sourceforge.net  Thu May 16 11:43:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 03:43:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E178IjH-0003vu-00@usw-sf-web4.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 11:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-16 12:43

Message:
Logged In: YES 
user_id=21627

I'm in favour of a you-may-mutate-the-buffer flag. A
transition strategy would be:
- in 2.3, make the flag optional, with default 0
- in 2.4, warn if it is not specified
- in 2.5, change the default
All the time, if the buffer isn't mutable, specifying the
flag should not be required.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-16 12:34

Message:
Logged In: YES 
user_id=29957

Hm. The solaris /proc lib I did in python, I used 'struct'
to dismantle C structures, but I did consider using byte
arrays. So that's one data point. 
(ok, it's not ioctls, but it's similar sort of data).
I'm loathe to go down the 'argument is mutable' optional
flag, but I really would prefer to make this work rather
than the ioctl2() approach, which really ain't that nice.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 11:21

Message:
Logged In: YES 
user_id=6656

I'm not *trying* to be a party-pooper, but there's another
problem: the point of passing a mutable array is so that
fcntl.ioctl can return ioctl(2)'s return code rather than
the string it returns now.  So if someone does use arrays
(or I guess Numeric.arrays?) for ioctls this would very
likely cause breakage.  I don't know how likely that is. 
Probably not very.  But I know that if this change broke my
code, I'd be a bit miffed.

All this is a bit annoying, as mutating arrays is clearly
the right solution -- where's that time machine?

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-16 00:50

Message:
Logged In: YES 
user_id=543663

I just realised - using array objects and changing in-place 
oversomes the arbitrary limit of 1024 bytes.  We could then 
achieve the full 16384 byte nirvana - hurrah!


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 19:21

Message:
Logged In: YES 
user_id=21627

I would not be concerned about the backwards compatibility,
either: if anybody is passing arrays, there is a good chance
that the ioctl does not modify the buffer, or that the
caller would not worry about the (missing) modification - or
else we had seen reports before.

So documenting in Misc/NEWS and the documentation that
mutable  objects supporting the (write) buffer interface may
now mutate seems sufficient.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 18:32

Message:
Logged In: YES 
user_id=543663

Thanks Michael, its all incredibly clear now (sorry Martin).

I think using arrays sounds a great idea.
IMVHO as to backward compatibility, AFAICT its not 
documented that arrays can be passed to ioctl() anyway (only 
says int and string no?), so it's only breaking undocumented 
behaviour.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-15 17:38

Message:
Logged In: YES 
user_id=6656

grahamh: I think Martin understood you fine.

Remember that arrays are mutable, whereas strings are not.

So the idea would be that you'd write

buf = array.array('c', '\000'*256)
ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf)

then the first "ret" bytes of "buf" would be valid.

However this possibly breaks backwards compatibility, as you
can already pass arrays into the ioctl function and they are
not modified.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 16:44

Message:
Logged In: YES 
user_id=543663

Re Loewis:
Not sure what you mean, perhaps an example of the 
problem from me would help:

In C:
    char buf[256], strbuf[256];
    int ret, fd;
    fd = open(...)
    ret = ioctl(fd, IOCTL_NUMBER, buf);
    strncpy(strbuf, buf, ret);

This is impossible with the current fcntl module:
    buf = "X" * struct.calcsize("256s")
    buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf)
    # The positive ioctl() return value is lost, and
    # hence I dont know how much of buf is significant

Extract from asm/unistd.h:

#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

So positive values are valid, but are being lost.

Anthony's patch looks good (thanks, I have not had a 
chance to test it myself yet), and the above example would 
be:
    buf = "X" * struct.calcsize("256s")
    ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf)
    strbuf = buf[:ret] # Result!

Now, to test my understanding of your last comment about 
array objects Loewis, do you mean:
- pass in a mutable list that gets changed in place to [ret, 
buf]
- return (ret, buf) if called like this: ioctl(fd, IOC, [buf])
- or something else - please give example.

Thanks people.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 14:04

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 14:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 12:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470



From noreply@sourceforge.net  Thu May 16 12:03:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 04:03:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E178J2K-0004CN-00@usw-sf-web4.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 09:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-05-16 11:03

Message:
Logged In: YES 
user_id=6656

OK, that would seem to be easy enough to implement (well,
the handling of writeable buffers, not all the optional
hair).  I like this:

>>> buf = array.array('h', [0]*4)
[19139 refs]
>>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf)
0
[19139 refs]
>>> buf
array('h', [47, 137, 841, 615])
[19139 refs]

I like this less:

>>> import array, fcntl
[19089 refs]
>>> buf = array.array('h', [0]*3)
[19093 refs]
>>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf)
0
[19095 refs]
>>> del buf
Debug memory block at address p=0x401c3cb8:
    6 bytes originally requested
    The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected.
    The 4 pad bytes at tail=0x401c3cbe are not all
FORBIDDENBYTE (0xfb):
        at tail+0: 0x67 *** OUCH
        at tail+1: 0x02 *** OUCH
        at tail+2: 0xfb
        at tail+3: 0xfb
    The block was made by call #16015 to debug malloc/realloc.
    Data at p: 2f 00 89 00 49 03
Fatal Python error: bad trailing pad byte
Aborted

I'm not sure what we can possibly do about this?  Copy into
a fixed buffer like we do today, then copy out again after
the ioctl?  Probably the best option.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-16 10:43

Message:
Logged In: YES 
user_id=21627

I'm in favour of a you-may-mutate-the-buffer flag. A
transition strategy would be:
- in 2.3, make the flag optional, with default 0
- in 2.4, warn if it is not specified
- in 2.5, change the default
All the time, if the buffer isn't mutable, specifying the
flag should not be required.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-16 10:34

Message:
Logged In: YES 
user_id=29957

Hm. The solaris /proc lib I did in python, I used 'struct'
to dismantle C structures, but I did consider using byte
arrays. So that's one data point. 
(ok, it's not ioctls, but it's similar sort of data).
I'm loathe to go down the 'argument is mutable' optional
flag, but I really would prefer to make this work rather
than the ioctl2() approach, which really ain't that nice.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 09:21

Message:
Logged In: YES 
user_id=6656

I'm not *trying* to be a party-pooper, but there's another
problem: the point of passing a mutable array is so that
fcntl.ioctl can return ioctl(2)'s return code rather than
the string it returns now.  So if someone does use arrays
(or I guess Numeric.arrays?) for ioctls this would very
likely cause breakage.  I don't know how likely that is. 
Probably not very.  But I know that if this change broke my
code, I'd be a bit miffed.

All this is a bit annoying, as mutating arrays is clearly
the right solution -- where's that time machine?

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 22:50

Message:
Logged In: YES 
user_id=543663

I just realised - using array objects and changing in-place 
oversomes the arbitrary limit of 1024 bytes.  We could then 
achieve the full 16384 byte nirvana - hurrah!


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 17:21

Message:
Logged In: YES 
user_id=21627

I would not be concerned about the backwards compatibility,
either: if anybody is passing arrays, there is a good chance
that the ioctl does not modify the buffer, or that the
caller would not worry about the (missing) modification - or
else we had seen reports before.

So documenting in Misc/NEWS and the documentation that
mutable  objects supporting the (write) buffer interface may
now mutate seems sufficient.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 16:32

Message:
Logged In: YES 
user_id=543663

Thanks Michael, its all incredibly clear now (sorry Martin).

I think using arrays sounds a great idea.
IMVHO as to backward compatibility, AFAICT its not 
documented that arrays can be passed to ioctl() anyway (only 
says int and string no?), so it's only breaking undocumented 
behaviour.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-15 15:38

Message:
Logged In: YES 
user_id=6656

grahamh: I think Martin understood you fine.

Remember that arrays are mutable, whereas strings are not.

So the idea would be that you'd write

buf = array.array('c', '\000'*256)
ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf)

then the first "ret" bytes of "buf" would be valid.

However this possibly breaks backwards compatibility, as you
can already pass arrays into the ioctl function and they are
not modified.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 14:44

Message:
Logged In: YES 
user_id=543663

Re Loewis:
Not sure what you mean, perhaps an example of the 
problem from me would help:

In C:
    char buf[256], strbuf[256];
    int ret, fd;
    fd = open(...)
    ret = ioctl(fd, IOCTL_NUMBER, buf);
    strncpy(strbuf, buf, ret);

This is impossible with the current fcntl module:
    buf = "X" * struct.calcsize("256s")
    buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf)
    # The positive ioctl() return value is lost, and
    # hence I dont know how much of buf is significant

Extract from asm/unistd.h:

#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

So positive values are valid, but are being lost.

Anthony's patch looks good (thanks, I have not had a 
chance to test it myself yet), and the above example would 
be:
    buf = "X" * struct.calcsize("256s")
    ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf)
    strbuf = buf[:ret] # Result!

Now, to test my understanding of your last comment about 
array objects Loewis, do you mean:
- pass in a mutable list that gets changed in place to [ret, 
buf]
- return (ret, buf) if called like this: ioctl(fd, IOC, [buf])
- or something else - please give example.

Thanks people.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 12:04

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 12:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 10:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470



From noreply@sourceforge.net  Thu May 16 12:41:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 04:41:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E178Jd9-0004dF-00@usw-sf-web4.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 09:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-05-16 11:41

Message:
Logged In: YES 
user_id=6656

Try the attached.

(a) should have docs.  This is getting hairy (if this then
that, but if this and not that then the other...).
(b) I've made no attempt to get this to hand out sane error
messages (see above).
(c) would be nice to have tests.  how on earth do you test
ioctl?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 11:03

Message:
Logged In: YES 
user_id=6656

OK, that would seem to be easy enough to implement (well,
the handling of writeable buffers, not all the optional
hair).  I like this:

>>> buf = array.array('h', [0]*4)
[19139 refs]
>>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf)
0
[19139 refs]
>>> buf
array('h', [47, 137, 841, 615])
[19139 refs]

I like this less:

>>> import array, fcntl
[19089 refs]
>>> buf = array.array('h', [0]*3)
[19093 refs]
>>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf)
0
[19095 refs]
>>> del buf
Debug memory block at address p=0x401c3cb8:
    6 bytes originally requested
    The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected.
    The 4 pad bytes at tail=0x401c3cbe are not all
FORBIDDENBYTE (0xfb):
        at tail+0: 0x67 *** OUCH
        at tail+1: 0x02 *** OUCH
        at tail+2: 0xfb
        at tail+3: 0xfb
    The block was made by call #16015 to debug malloc/realloc.
    Data at p: 2f 00 89 00 49 03
Fatal Python error: bad trailing pad byte
Aborted

I'm not sure what we can possibly do about this?  Copy into
a fixed buffer like we do today, then copy out again after
the ioctl?  Probably the best option.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-16 10:43

Message:
Logged In: YES 
user_id=21627

I'm in favour of a you-may-mutate-the-buffer flag. A
transition strategy would be:
- in 2.3, make the flag optional, with default 0
- in 2.4, warn if it is not specified
- in 2.5, change the default
All the time, if the buffer isn't mutable, specifying the
flag should not be required.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-16 10:34

Message:
Logged In: YES 
user_id=29957

Hm. The solaris /proc lib I did in python, I used 'struct'
to dismantle C structures, but I did consider using byte
arrays. So that's one data point. 
(ok, it's not ioctls, but it's similar sort of data).
I'm loathe to go down the 'argument is mutable' optional
flag, but I really would prefer to make this work rather
than the ioctl2() approach, which really ain't that nice.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 09:21

Message:
Logged In: YES 
user_id=6656

I'm not *trying* to be a party-pooper, but there's another
problem: the point of passing a mutable array is so that
fcntl.ioctl can return ioctl(2)'s return code rather than
the string it returns now.  So if someone does use arrays
(or I guess Numeric.arrays?) for ioctls this would very
likely cause breakage.  I don't know how likely that is. 
Probably not very.  But I know that if this change broke my
code, I'd be a bit miffed.

All this is a bit annoying, as mutating arrays is clearly
the right solution -- where's that time machine?

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 22:50

Message:
Logged In: YES 
user_id=543663

I just realised - using array objects and changing in-place 
oversomes the arbitrary limit of 1024 bytes.  We could then 
achieve the full 16384 byte nirvana - hurrah!


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 17:21

Message:
Logged In: YES 
user_id=21627

I would not be concerned about the backwards compatibility,
either: if anybody is passing arrays, there is a good chance
that the ioctl does not modify the buffer, or that the
caller would not worry about the (missing) modification - or
else we had seen reports before.

So documenting in Misc/NEWS and the documentation that
mutable  objects supporting the (write) buffer interface may
now mutate seems sufficient.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 16:32

Message:
Logged In: YES 
user_id=543663

Thanks Michael, its all incredibly clear now (sorry Martin).

I think using arrays sounds a great idea.
IMVHO as to backward compatibility, AFAICT its not 
documented that arrays can be passed to ioctl() anyway (only 
says int and string no?), so it's only breaking undocumented 
behaviour.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-15 15:38

Message:
Logged In: YES 
user_id=6656

grahamh: I think Martin understood you fine.

Remember that arrays are mutable, whereas strings are not.

So the idea would be that you'd write

buf = array.array('c', '\000'*256)
ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf)

then the first "ret" bytes of "buf" would be valid.

However this possibly breaks backwards compatibility, as you
can already pass arrays into the ioctl function and they are
not modified.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-15 14:44

Message:
Logged In: YES 
user_id=543663

Re Loewis:
Not sure what you mean, perhaps an example of the 
problem from me would help:

In C:
    char buf[256], strbuf[256];
    int ret, fd;
    fd = open(...)
    ret = ioctl(fd, IOCTL_NUMBER, buf);
    strncpy(strbuf, buf, ret);

This is impossible with the current fcntl module:
    buf = "X" * struct.calcsize("256s")
    buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf)
    # The positive ioctl() return value is lost, and
    # hence I dont know how much of buf is significant

Extract from asm/unistd.h:

#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

So positive values are valid, but are being lost.

Anthony's patch looks good (thanks, I have not had a 
chance to test it myself yet), and the above example would 
be:
    buf = "X" * struct.calcsize("256s")
    ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf)
    strbuf = buf[:ret] # Result!

Now, to test my understanding of your last comment about 
array objects Loewis, do you mean:
- pass in a mutable list that gets changed in place to [ret, 
buf]
- return (ret, buf) if called like this: ioctl(fd, IOC, [buf])
- or something else - please give example.

Thanks people.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 12:04

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 12:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 10:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470



From noreply@sourceforge.net  Thu May 16 13:15:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 05:15:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation.
Message-ID: <E178KAS-00049v-00@usw-sf-web2.sourceforge.net>

Bugs item #555817, was opened at 2002-05-14 19:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Graham Horler (grahamh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Flawed fcntl.ioctl implementation.

Initial Comment:
I'm doing some USB user-space driver programming 
in Python 2.1.3 under Linux 2.4.

When using a particular ioctl (HIDIOCGNAME), the 
return value as well as the (copy_to_user) binary data 
is significant.

Here is the code from line 547 of hiddev.c (kernel 
2.4.19-pre7):
  if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) {
    int len;
    if (!hid->name) return 0;
    len = strlen(hid->name) + 1;
    if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd);
    return copy_to_user((char *) arg, hid->name, len) ?
      -EFAULT : len;
  }

So here is the problem:  fcntl.ioctl() will only give me 
one or the other value, but not both.

I can work around this by initialising the input buffer to 
all chr(0), and then strip them off after.  But there will 
be a time when an ioctl call *requires* both values.

Until now I have appreciated the simple ioctl interface, 
but now it is shown to be an oversimplification.

It may be that POSIX, or some standard somewhere 
says that ioctl should not be used to do this, but 
maybe Python should support it anyway.

I suggest either:
1.  A new function ioctl2(fd, op, arg) that returns a 
2-tuple of (return_value, binary_buffer) and does not 
try to interpret the return value.
2.  An optional 4th parameter whose presence (but 
not value) requests the 2-tuple mentioned in (1).

Gotta love Python!

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-16 22:15

Message:
Logged In: YES 
user_id=29957

There's a very simple test_ioctl.py in 
patch #555883 (the ioctl2() sample implementation).
It does a getpgrp(), then a TIOCGPGRP and checks 
it gets the same stuff. No, it won't work on Windows.

I'm going to close off #555883 as Invalid.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 21:41

Message:
Logged In: YES 
user_id=6656

Try the attached.

(a) should have docs.  This is getting hairy (if this then
that, but if this and not that then the other...).
(b) I've made no attempt to get this to hand out sane error
messages (see above).
(c) would be nice to have tests.  how on earth do you test
ioctl?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 21:03

Message:
Logged In: YES 
user_id=6656

OK, that would seem to be easy enough to implement (well,
the handling of writeable buffers, not all the optional
hair).  I like this:

>>> buf = array.array('h', [0]*4)
[19139 refs]
>>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf)
0
[19139 refs]
>>> buf
array('h', [47, 137, 841, 615])
[19139 refs]

I like this less:

>>> import array, fcntl
[19089 refs]
>>> buf = array.array('h', [0]*3)
[19093 refs]
>>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf)
0
[19095 refs]
>>> del buf
Debug memory block at address p=0x401c3cb8:
    6 bytes originally requested
    The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected.
    The 4 pad bytes at tail=0x401c3cbe are not all
FORBIDDENBYTE (0xfb):
        at tail+0: 0x67 *** OUCH
        at tail+1: 0x02 *** OUCH
        at tail+2: 0xfb
        at tail+3: 0xfb
    The block was made by call #16015 to debug malloc/realloc.
    Data at p: 2f 00 89 00 49 03
Fatal Python error: bad trailing pad byte
Aborted

I'm not sure what we can possibly do about this?  Copy into
a fixed buffer like we do today, then copy out again after
the ioctl?  Probably the best option.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-16 20:43

Message:
Logged In: YES 
user_id=21627

I'm in favour of a you-may-mutate-the-buffer flag. A
transition strategy would be:
- in 2.3, make the flag optional, with default 0
- in 2.4, warn if it is not specified
- in 2.5, change the default
All the time, if the buffer isn't mutable, specifying the
flag should not be required.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-16 20:34

Message:
Logged In: YES 
user_id=29957

Hm. The solaris /proc lib I did in python, I used 'struct'
to dismantle C structures, but I did consider using byte
arrays. So that's one data point. 
(ok, it's not ioctls, but it's similar sort of data).
I'm loathe to go down the 'argument is mutable' optional
flag, but I really would prefer to make this work rather
than the ioctl2() approach, which really ain't that nice.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 19:21

Message:
Logged In: YES 
user_id=6656

I'm not *trying* to be a party-pooper, but there's another
problem: the point of passing a mutable array is so that
fcntl.ioctl can return ioctl(2)'s return code rather than
the string it returns now.  So if someone does use arrays
(or I guess Numeric.arrays?) for ioctls this would very
likely cause breakage.  I don't know how likely that is. 
Probably not very.  But I know that if this change broke my
code, I'd be a bit miffed.

All this is a bit annoying, as mutating arrays is clearly
the right solution -- where's that time machine?

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-16 08:50

Message:
Logged In: YES 
user_id=543663

I just realised - using array objects and changing in-place 
oversomes the arbitrary limit of 1024 bytes.  We could then 
achieve the full 16384 byte nirvana - hurrah!


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-16 03:21

Message:
Logged In: YES 
user_id=21627

I would not be concerned about the backwards compatibility,
either: if anybody is passing arrays, there is a good chance
that the ioctl does not modify the buffer, or that the
caller would not worry about the (missing) modification - or
else we had seen reports before.

So documenting in Misc/NEWS and the documentation that
mutable  objects supporting the (write) buffer interface may
now mutate seems sufficient.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-16 02:32

Message:
Logged In: YES 
user_id=543663

Thanks Michael, its all incredibly clear now (sorry Martin).

I think using arrays sounds a great idea.
IMVHO as to backward compatibility, AFAICT its not 
documented that arrays can be passed to ioctl() anyway (only 
says int and string no?), so it's only breaking undocumented 
behaviour.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-16 01:38

Message:
Logged In: YES 
user_id=6656

grahamh: I think Martin understood you fine.

Remember that arrays are mutable, whereas strings are not.

So the idea would be that you'd write

buf = array.array('c', '\000'*256)
ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf)

then the first "ret" bytes of "buf" would be valid.

However this possibly breaks backwards compatibility, as you
can already pass arrays into the ioctl function and they are
not modified.

----------------------------------------------------------------------

Comment By: Graham Horler (grahamh)
Date: 2002-05-16 00:44

Message:
Logged In: YES 
user_id=543663

Re Loewis:
Not sure what you mean, perhaps an example of the 
problem from me would help:

In C:
    char buf[256], strbuf[256];
    int ret, fd;
    fd = open(...)
    ret = ioctl(fd, IOCTL_NUMBER, buf);
    strncpy(strbuf, buf, ret);

This is impossible with the current fcntl module:
    buf = "X" * struct.calcsize("256s")
    buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf)
    # The positive ioctl() return value is lost, and
    # hence I dont know how much of buf is significant

Extract from asm/unistd.h:

#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

So positive values are valid, but are being lost.

Anthony's patch looks good (thanks, I have not had a 
chance to test it myself yet), and the above example would 
be:
    buf = "X" * struct.calcsize("256s")
    ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf)
    strbuf = buf[:ret] # Result!

Now, to test my understanding of your last comment about 
array objects Loewis, do you mean:
- pass in a mutable list that gets changed in place to [ret, 
buf]
- return (ret, buf) if called like this: ioctl(fd, IOC, [buf])
- or something else - please give example.

Thanks people.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 22:04

Message:
Logged In: YES 
user_id=21627

Thinking about the problem again, I think the right solution
would be to support array objects as arguments to ioctl -
those would then be passed into the system call.

Am I correctly understanding the problem, that this would
not require a new function?

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 22:06

Message:
Logged In: YES 
user_id=29957

possible patch at
http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470
I've only lightly tested it, not with any calls that return
useful values in the return code (couldn't find any easily, 
didn't feel like figuring out userspace drivers right now :)
Give it a whirl...

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-05-14 20:10

Message:
Logged In: YES 
user_id=29957

Ouch. I think you're right - and I think that the
ioctl2() implementation is probably the only solution.
(I'm not so keen on the name, but I guess it kinda 
follows the 'standard' of other python functions, e.g.
popen)
I know changing the return of ioctl would be mega-ugly,
unless there was a new, optional "return a tuple"
argument. I doubt that's the appropriate fix. 

If the former approach is the appropriate one, it should
be simple enough to add an ioctl2() to the C source. I 
can probably whip it up now...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470



From noreply@sourceforge.net  Thu May 16 15:34:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 07:34:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-532467 ] 6.9 The raise statement is confusing
Message-ID: <E178MKl-0006eG-00@usw-sf-web4.sourceforge.net>

Bugs item #532467, was opened at 2002-03-20 07:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick K. O'Brien (pobrien)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 6.9 The raise statement is confusing

Initial Comment:
The description supplied for "6.9 The raise statement" 
is confusing. In particular, it starts by explaining 
the intent of each "expresssion" and midway switches 
to "object" instead of expression. In particular, I 
can't make heads or tails out of the following passage:

"If the first object is a string, it then raises the 
exception identified by the first object, with the 
second one (or None) as its parameter. If the first 
object is a class or instance, it raises the exception 
identified by the class of the instance determined in 
the previous step, with the instance as its parameter."

----------------------------------------------------------------------

>Comment By: Patrick K. O'Brien (pobrien)
Date: 2002-05-16 09:34

Message:
Logged In: YES 
user_id=179604

Raymond, I really appreciate your patches. The big patch is 
terrific and gets my vote. I do have one more request for 
clarification in what you wrote. You say:

"If the first expression is a class object, it raises the 
exception identified by the class of an instance determined 
by the second expression.  If the second expression is an 
instance, that instance is used."

So we're talking about the form: raise class, instance

What I'm picturing is a situation where the second 
expression is an instance of a class other than the class 
object used as the first expression. Is this allowed, 
disallowed, allowed but nonsensical or allowed because it 
offers some practical benefit that I'm just not grasping?

I found and read the essay on "Standard Exception Classes 
in Python 1.5" 
(http://www.python.org/doc/essays/stdexceptions.html) and I 
can see that much was done to maintain backward 
compatibility. and apparently the "raise class, instance" 
form goes back quite a ways. Is this just a wart to be 
avoided? I'm probably expecting too much to expect the 
language reference to distinguish between what is strictly 
allowed vs. why it is allowed and whether it should even be 
used at all. It's just that the more I dug into this the 
more confused I became. I think I'm understanding the 
situation now.

In any case, make of this what you will. The bottom line is 
that your batch is definitely an improvement and I greatly 
appreciate your time and effort on this. Thanks.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 23:10

Message:
Logged In: YES 
user_id=80475

Attached two alternative patches.

The first makes minimal changes to achieve a clear and 
consistent use of "objects" versus "expressions".

The second alternative re-paragraphs the text and uses 
parallel sentence contruction to provide (IMHO) 
greater clarity without getting a headache reading it.

If accepted, please re-assign to Raymond for a commit to 
2.3 and to release22-maint.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470



From noreply@sourceforge.net  Fri May 17 00:05:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 16:05:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E178UJF-000470-00@usw-sf-web4.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



----------------------------------------------------------------------

Comment By: Martin D Katz, Ph.D. (drbits)
Date: 2002-05-16 16:05

Message:
Logged In: YES 
user_id=276840

I have not been able to get the btopen format of bsddb to 
fail in the ActiveState distribution (for Windows). This is 
version 1.85. Has anybody seen a failure with the btopen 
format?

The Sleepycat license (versions 2.0 and later) is similar 
to the original GPL, it allows free use of the software as 
long as the product in which it contains is open source. 

Commercial use of the newer versions requires that either 
the entire product be open source or paument of a (rather 
steep) license fee.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-10-18 15:43

Message:
Logged In: YES 
user_id=12800

I'm finally closing this bug report.  With my Mandrake
7.2-ish system I get bsddb 3 by default and there seems to
be no problem inserting several hundred thousand items (I
killed it after 205k+).  So it's very likely that the
reported problems were due to the extremely old db 1.85.

Note though, that it should be okay license-wise if we
wanted to distribute the latest Sleepycat library (currently
3.3.11) with Python.  I've had personal conversations with
the Sleepycat guys, and they've said that their read on
their own license would allow this.  We'd want to get it in
writing first I think, and we'd have to ask about the
binary-only Windows distros, but I think it would be okay. 
If we did this, we should also distribute Robin Dunn's
excellent PyBSDDB3.

No time for this in Python 2.2, but let's look at it again
for Python 2.3.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-04 20:35

Message:
Logged In: YES 
user_id=31435

Barry apparently forgot to assign this to himself; repaired 
his bug <wink>.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-04 19:59

Message:
Logged In: YES 
user_id=12800

if you can live with the licensing for sleepycat's db3, do 
yourself a huge favor and go to pybsddb.sf.net.  robin 
dunn's got a very excellent, stable, new python binding, 
which i would like to integrate into the standard distro 
for the py2.2 release.  it claims to support db1.85, 
although i've only tried it with a very recent v3.9.x.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-04 19:42

Message:
Logged In: YES 
user_id=44345

   I don't know anything about the history, present, or 
   prospects for bsddb -- like, is there a more recent 
   unencumbered version we could use?

Ya got me.  I've been using lib db 2 for quite awhile.  They
recently released lib db 3 (again, with file format incom-
patibilities).  I don't know the details of their license.
It just comes with whatever version of Linux I happen to be
running.

Saw this on the Sleepycat website:

   The Berkeley DB 3.0 source code is available for download
   at no charge from Sleepycat Software's Web site, at
   www.sleepycat.com. It runs on all common versions of
   UNIX, and on Windows 95, Windows 98 and Windows NT.
   Berkeley DB is an Open Source product, and may be
   redistributed without charge in many circumstances.
   Licensing and pricing information are available from
   the company. 

My guess would be that you can distribute lib db 3 with 
the binary version of Python.  I am, as they say, "not
a lawyer", so YMMV.  For a definitive answer I think
you'll have to ask Sleepycat.

Skip


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-04 17:02

Message:
Logged In: YES 
user_id=31435

Skip, I reran the test after changing the open line to

db = bsddb.btopen("test.dbm", "n")

I killed it by hand at this point:

Last i: 326577, last key:abcdef4387101.63608

because Win98SE gets mondo unstable when it starts 
thrashing madly to disk, and it became impossible to get 
any work done while this was running.

I don't know anything about the history, present, or 
prospects for bsddb -- like, is there a more recent 
unencumbered version we could use?  It looks like Sam's 
1.85 Windows port is over 5 years old.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-04 15:59

Message:
Logged In: NO 

According to www.sleepycat.com/historic.html, 
talking about bsd db:
"we recommend that you avoid the following operations when 
using versions 1.85 and 1.86: 

o Btree cursor (seq and put using a cursor) operations. 
o Large numbers of btree duplicates (specifically, avoid 
migrating duplicate keys to internal pages). 
o Large numbers of btree deletes (you should periodically 
dump and rebuild the database if you delete large numbers 
of records). 
o Overwriting or deleting overflow hash key/data pairs 
(pairs with items larger than the page size). 
o Intermixing hash cursor operations with deletes. "


My problem arises, I think, because I have been doing the 
fourth of these operations - i.e. overwriting long items in 
a hash. The problems others are experiencing perhaps have a 
similar cause, though the original problem summary 
says "even with a value size of 1 the bug will occur", so 
perhaps not.

I'm now using a workaround which involves writing several 
shorter items, each containing a slice of the data formerly 
held in the one long item. For keys I use my old key with a 
subscript number appended. It isn't nice, but it seems to 
be working.

Martin Gradwell.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-04 08:12

Message:
Logged In: YES 
user_id=44345

Based upon the traceback Tim reported, my guess is that 
the exception is being raised near the end of bsddb_ass_sub.
Tim, can you give it a try changing anydbm.open to
bsddb.btopen?  As I recall, the significant bug(s) in libdb
were in the hash file implementation.  It's unfortunate
that anydbm has used the hash file all these years, but
it's a bit late to spring that change on unsuspecting
users now without going through a significant transition
period.

Skip


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-03 14:40

Message:
Logged In: YES 
user_id=31435

Thanks for taking a look, Skip!  On Win98SE it dies for me 
like so:

...
70000
71000
72000
Last i: 72758, last key:abcdef1691515.8934
Traceback (most recent call last):
  File "ka.py", line 15, in ?
    db[key] = val
bsddb.error: (0, 'Error')

test.dbm is 37,778,944 bytes at the end.  I assume 
Anonymous has the same problem (if not, he/she should say 
so).

On Windows we use the ancient db.1.85.win32.zip, from 
the "bsd db" (not "bsddb"!) link at

http://www.nightmare.com/software.html

I doubt Sam has done any maintenance on that in years; and 
afraid I don't know anything else about this.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-03 13:25

Message:
Logged In: YES 
user_id=44345

What version of libdb are you using?  I'm running your
script on Linux at the moment.  I had to change it slightly
because the only machine I have available with the spare 
cojones to run that script is running 1.5.2 (so I call
random.uniform instead of using a Random instance).  On that
machine I'm sort of ashamed to say I'm still running the
known buggy libdb 1.85.  So far I'm up to 680,000 keys with
a db file of over 166MB with no problem.  On my laptop
running 2.1 and libdb3 (and a much more modestly performing
disk drive) I gave up after about 287,000 keys.
I then changed the db open call to bsddb.btopen and watched
it march (slowly) up to 183,000 keys and a 32MB file on
disk before I killed it.  Aside from the grief it gives my
disk drives, I don't see anything particularly bad
happening.

You didn't include a traceback with your bug report.  What
was printed?  Perhaps it's something simple like running
out of disk space.  In any case, I think trying to create a
libdb database of 1,000,000 sort of random keys is going to
strain that package and most disk drives in any case, bugs
or no bugs.

My guess is that if there's a bug it's in libdb, not the
bsddb module.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-03 00:50

Message:
Logged In: NO 

Here it is:

import anydbm
import bsddb
import random

MAX = 1000000
r = random.Random(42)
r.seed(1017)
db = anydbm.open("test.dbm", "n")
#db = bsddb.hashopen("test.dbm", "n")
try:
    for i in xrange(0, MAX):
        if i % 1000 == 0: print i
        key = "abcdef" + str(r.uniform(0, 10 * MAX))
        val = "a" * 80 + str(i)
        db[key] = val
finally:
    db.close()
    print "Last i: %s, last key:%s" % (i,key) 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-02 12:41

Message:
Logged In: YES 
user_id=31435

Alas, there's no script attached -- please attach one, so 
we have something concrete to investigate.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 03:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470



From noreply@sourceforge.net  Fri May 17 00:55:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 16:55:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E178V5M-0003ic-00@usw-sf-web2.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 02:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-05-16 18:55

Message:
Logged In: YES 
user_id=44345

Probably overkill, but I will chime in.  I let the 
script run to about 400k iterations without problem.  
Back in the old days (circa 1995-6) I conciously 
switched from hashopen to btopen precisely because the 
1.85 library had known bugs in its hash implementation 
(that corrupted my databases).  I never had any problem 
with the btree file format.

Skip


----------------------------------------------------------------------

Comment By: Martin D Katz, Ph.D. (drbits)
Date: 2002-05-16 18:05

Message:
Logged In: YES 
user_id=276840

I have not been able to get the btopen format of bsddb to 
fail in the ActiveState distribution (for Windows). This is 
version 1.85. Has anybody seen a failure with the btopen 
format?

The Sleepycat license (versions 2.0 and later) is similar 
to the original GPL, it allows free use of the software as 
long as the product in which it contains is open source. 

Commercial use of the newer versions requires that either 
the entire product be open source or paument of a (rather 
steep) license fee.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-10-18 17:43

Message:
Logged In: YES 
user_id=12800

I'm finally closing this bug report.  With my Mandrake
7.2-ish system I get bsddb 3 by default and there seems to
be no problem inserting several hundred thousand items (I
killed it after 205k+).  So it's very likely that the
reported problems were due to the extremely old db 1.85.

Note though, that it should be okay license-wise if we
wanted to distribute the latest Sleepycat library (currently
3.3.11) with Python.  I've had personal conversations with
the Sleepycat guys, and they've said that their read on
their own license would allow this.  We'd want to get it in
writing first I think, and we'd have to ask about the
binary-only Windows distros, but I think it would be okay. 
If we did this, we should also distribute Robin Dunn's
excellent PyBSDDB3.

No time for this in Python 2.2, but let's look at it again
for Python 2.3.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-04 22:35

Message:
Logged In: YES 
user_id=31435

Barry apparently forgot to assign this to himself; repaired 
his bug <wink>.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-04 21:59

Message:
Logged In: YES 
user_id=12800

if you can live with the licensing for sleepycat's db3, do 
yourself a huge favor and go to pybsddb.sf.net.  robin 
dunn's got a very excellent, stable, new python binding, 
which i would like to integrate into the standard distro 
for the py2.2 release.  it claims to support db1.85, 
although i've only tried it with a very recent v3.9.x.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-04 21:42

Message:
Logged In: YES 
user_id=44345

   I don't know anything about the history, present, or 
   prospects for bsddb -- like, is there a more recent 
   unencumbered version we could use?

Ya got me.  I've been using lib db 2 for quite awhile.  They
recently released lib db 3 (again, with file format incom-
patibilities).  I don't know the details of their license.
It just comes with whatever version of Linux I happen to be
running.

Saw this on the Sleepycat website:

   The Berkeley DB 3.0 source code is available for download
   at no charge from Sleepycat Software's Web site, at
   www.sleepycat.com. It runs on all common versions of
   UNIX, and on Windows 95, Windows 98 and Windows NT.
   Berkeley DB is an Open Source product, and may be
   redistributed without charge in many circumstances.
   Licensing and pricing information are available from
   the company. 

My guess would be that you can distribute lib db 3 with 
the binary version of Python.  I am, as they say, "not
a lawyer", so YMMV.  For a definitive answer I think
you'll have to ask Sleepycat.

Skip


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-04 19:02

Message:
Logged In: YES 
user_id=31435

Skip, I reran the test after changing the open line to

db = bsddb.btopen("test.dbm", "n")

I killed it by hand at this point:

Last i: 326577, last key:abcdef4387101.63608

because Win98SE gets mondo unstable when it starts 
thrashing madly to disk, and it became impossible to get 
any work done while this was running.

I don't know anything about the history, present, or 
prospects for bsddb -- like, is there a more recent 
unencumbered version we could use?  It looks like Sam's 
1.85 Windows port is over 5 years old.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-04 17:59

Message:
Logged In: NO 

According to www.sleepycat.com/historic.html, 
talking about bsd db:
"we recommend that you avoid the following operations when 
using versions 1.85 and 1.86: 

o Btree cursor (seq and put using a cursor) operations. 
o Large numbers of btree duplicates (specifically, avoid 
migrating duplicate keys to internal pages). 
o Large numbers of btree deletes (you should periodically 
dump and rebuild the database if you delete large numbers 
of records). 
o Overwriting or deleting overflow hash key/data pairs 
(pairs with items larger than the page size). 
o Intermixing hash cursor operations with deletes. "


My problem arises, I think, because I have been doing the 
fourth of these operations - i.e. overwriting long items in 
a hash. The problems others are experiencing perhaps have a 
similar cause, though the original problem summary 
says "even with a value size of 1 the bug will occur", so 
perhaps not.

I'm now using a workaround which involves writing several 
shorter items, each containing a slice of the data formerly 
held in the one long item. For keys I use my old key with a 
subscript number appended. It isn't nice, but it seems to 
be working.

Martin Gradwell.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-04 10:12

Message:
Logged In: YES 
user_id=44345

Based upon the traceback Tim reported, my guess is that 
the exception is being raised near the end of bsddb_ass_sub.
Tim, can you give it a try changing anydbm.open to
bsddb.btopen?  As I recall, the significant bug(s) in libdb
were in the hash file implementation.  It's unfortunate
that anydbm has used the hash file all these years, but
it's a bit late to spring that change on unsuspecting
users now without going through a significant transition
period.

Skip


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-03 16:40

Message:
Logged In: YES 
user_id=31435

Thanks for taking a look, Skip!  On Win98SE it dies for me 
like so:

...
70000
71000
72000
Last i: 72758, last key:abcdef1691515.8934
Traceback (most recent call last):
  File "ka.py", line 15, in ?
    db[key] = val
bsddb.error: (0, 'Error')

test.dbm is 37,778,944 bytes at the end.  I assume 
Anonymous has the same problem (if not, he/she should say 
so).

On Windows we use the ancient db.1.85.win32.zip, from 
the "bsd db" (not "bsddb"!) link at

http://www.nightmare.com/software.html

I doubt Sam has done any maintenance on that in years; and 
afraid I don't know anything else about this.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-03 15:25

Message:
Logged In: YES 
user_id=44345

What version of libdb are you using?  I'm running your
script on Linux at the moment.  I had to change it slightly
because the only machine I have available with the spare 
cojones to run that script is running 1.5.2 (so I call
random.uniform instead of using a Random instance).  On that
machine I'm sort of ashamed to say I'm still running the
known buggy libdb 1.85.  So far I'm up to 680,000 keys with
a db file of over 166MB with no problem.  On my laptop
running 2.1 and libdb3 (and a much more modestly performing
disk drive) I gave up after about 287,000 keys.
I then changed the db open call to bsddb.btopen and watched
it march (slowly) up to 183,000 keys and a 32MB file on
disk before I killed it.  Aside from the grief it gives my
disk drives, I don't see anything particularly bad
happening.

You didn't include a traceback with your bug report.  What
was printed?  Perhaps it's something simple like running
out of disk space.  In any case, I think trying to create a
libdb database of 1,000,000 sort of random keys is going to
strain that package and most disk drives in any case, bugs
or no bugs.

My guess is that if there's a bug it's in libdb, not the
bsddb module.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-03 02:50

Message:
Logged In: NO 

Here it is:

import anydbm
import bsddb
import random

MAX = 1000000
r = random.Random(42)
r.seed(1017)
db = anydbm.open("test.dbm", "n")
#db = bsddb.hashopen("test.dbm", "n")
try:
    for i in xrange(0, MAX):
        if i % 1000 == 0: print i
        key = "abcdef" + str(r.uniform(0, 10 * MAX))
        val = "a" * 80 + str(i)
        db[key] = val
finally:
    db.close()
    print "Last i: %s, last key:%s" % (i,key) 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-02 14:41

Message:
Logged In: YES 
user_id=31435

Alas, there's no script attached -- please attach one, so 
we have something concrete to investigate.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 05:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470



From noreply@sourceforge.net  Fri May 17 01:31:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 17:31:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-557028 ] illegal use of malloc/free
Message-ID: <E178Ves-0004z2-00@usw-sf-web4.sourceforge.net>

Bugs item #557028, was opened at 2002-05-17 02:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557028&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustav Hållberg (gurra-g)
Assigned to: Nobody/Anonymous (nobody)
Summary: illegal use of malloc/free

Initial Comment:
com_factor() in compiler.c uses malloc/free, but should
use PyMem_Malloc/_Free.

The use of malloc/free is fatal when one has changed
Python's allocators to use something else than
malloc/free since the stuff malloc:ed there can later
on be (attempted to be) freed through a call to PyMem_Free.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557028&group_id=5470



From noreply@sourceforge.net  Fri May 17 02:19:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 May 2002 18:19:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-557028 ] illegal use of malloc/free
Message-ID: <E178WOz-0004aH-00@usw-sf-web2.sourceforge.net>

Bugs item #557028, was opened at 2002-05-16 20:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557028&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustav Hållberg (gurra-g)
Assigned to: Nobody/Anonymous (nobody)
Summary: illegal use of malloc/free

Initial Comment:
com_factor() in compiler.c uses malloc/free, but should
use PyMem_Malloc/_Free.

The use of malloc/free is fatal when one has changed
Python's allocators to use something else than
malloc/free since the stuff malloc:ed there can later
on be (attempted to be) freed through a call to PyMem_Free.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-05-16 21:19

Message:
Logged In: YES 
user_id=31435

Just noting that current CVS already uses PyMem_ in 
com_factor.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557028&group_id=5470



From noreply@sourceforge.net  Fri May 17 11:46:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 May 2002 03:46:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-557028 ] illegal use of malloc/free
Message-ID: <E178fFs-0002cZ-00@usw-sf-web3.sourceforge.net>

Bugs item #557028, was opened at 2002-05-17 02:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557028&group_id=5470

Category: Parser/Compiler
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustav Hållberg (gurra-g)
Assigned to: Nobody/Anonymous (nobody)
Summary: illegal use of malloc/free

Initial Comment:
com_factor() in compiler.c uses malloc/free, but should
use PyMem_Malloc/_Free.

The use of malloc/free is fatal when one has changed
Python's allocators to use something else than
malloc/free since the stuff malloc:ed there can later
on be (attempted to be) freed through a call to PyMem_Free.


----------------------------------------------------------------------

>Comment By: Gustav Hållberg (gurra-g)
Date: 2002-05-17 12:46

Message:
Logged In: YES 
user_id=546849

Ah, that should definitely be backported to releasebranches.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-17 03:19

Message:
Logged In: YES 
user_id=31435

Just noting that current CVS already uses PyMem_ in 
com_factor.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557028&group_id=5470



From noreply@sourceforge.net  Fri May 17 21:22:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 May 2002 13:22:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E178oFN-00010y-00@usw-sf-web3.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470



From noreply@sourceforge.net  Fri May 17 21:25:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 May 2002 13:25:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E178oIW-000130-00@usw-sf-web3.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470



From noreply@sourceforge.net  Fri May 17 21:39:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 May 2002 13:39:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-557436 ] TclError is a str should be an Exception
Message-ID: <E178oVA-0001Bd-00@usw-sf-web3.sourceforge.net>

Bugs item #557436, was opened at 2002-05-17 16:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557436&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: TclError is a str should be an Exception

Initial Comment:
Since string exceptions are deprecated, it seems that
TclError (in _tkinter.c) should be changed to derive
from Exception.

It isn't apparent to me how to accomplish this.  If
someone can provide a quick high-level description, I
can make a patch.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557436&group_id=5470



From noreply@sourceforge.net  Fri May 17 22:03:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 May 2002 14:03:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E178osW-0001TJ-00@usw-sf-web3.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 17:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470



From noreply@sourceforge.net  Fri May 17 23:35:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 May 2002 15:35:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-557482 ] _builtinSuites is ignored
Message-ID: <E178qKJ-00022L-00@usw-sf-web2.sourceforge.net>

Bugs item #557482, was opened at 2002-05-17 15:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557482&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Parenteau (aubonbeurre)
Assigned to: Jack Jansen (jackjansen)
Summary: _builtinSuites is ignored

Initial Comment:
_builtinSuites is ignored from the Makefile inside 
python/dist/src/Mac/OSX/Makefile.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557482&group_id=5470



From noreply@sourceforge.net  Sat May 18 01:12:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 May 2002 17:12:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E178rpp-00036I-00@usw-sf-web2.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 11:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 19:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 15:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 15:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 19:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 17:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470



From noreply@sourceforge.net  Sat May 18 09:45:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 May 2002 01:45:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-557436 ] TclError is a str should be an Exception
Message-ID: <E178zpm-000085-00@usw-sf-web3.sourceforge.net>

Bugs item #557436, was opened at 2002-05-17 15:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557436&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: TclError is a str should be an Exception

Initial Comment:
Since string exceptions are deprecated, it seems that
TclError (in _tkinter.c) should be changed to derive
from Exception.

It isn't apparent to me how to accomplish this.  If
someone can provide a quick high-level description, I
can make a patch.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 03:45

Message:
Logged In: YES 
user_id=80475

Try makeclass() in Python/exceptions.c -- the file also 
shows how all the built-in exceptions get created.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557436&group_id=5470



From noreply@sourceforge.net  Sat May 18 18:18:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 May 2002 10:18:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E1797qy-0006U2-00@usw-sf-web1.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 19:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470



From noreply@sourceforge.net  Sat May 18 20:43:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 May 2002 12:43:09 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-538582 ] NTLM Authentication Using httplib
Message-ID: <E179A6f-0007BW-00@usw-sf-web3.sourceforge.net>

Feature Requests item #538582, was opened at 2002-04-03 01:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=538582&group_id=5470

Category: None
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Nobody/Anonymous (nobody)
Summary: NTLM Authentication Using httplib

Initial Comment:
Is there a way to use httplib to do NTLM 
authentication using the following URL format:

http://username:password@www.mydomain.com:80/start.py

???

If you attempt to do this it errors out (trying to 
make everything from ":password" over the port number).

Thank you in advance.

Keyton

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-03 12:01

Message:
Logged In: YES 
user_id=21627

Python does not support NTLM authentication; so this sounds
like a feature request (reclassifying it as such). urllib
supports Basic authentication.

I'm still not sure what you did  that was incorrectly
interpreted as a port number. Can you please provide a
precise sequence of Python statements, and report what the
precise error message is that you get?

----------------------------------------------------------------------

Comment By: Keyton Weissinger (keytonw)
Date: 2002-04-03 07:39

Message:
Logged In: YES 
user_id=396481

NTLM is the Windows NT authentication scheme for web 
applications. It is what triggers the 
domain/username/password input box that springs up on 
secure NT-based web applications.

To avoid the pop-up, people use a URL in the following 
format:

http://username:password@www.mydomain.com:80/myPage.htm

The bug:

When I enter a host string that looks like the above, the 
httplib code tries to make:

:password@www.mydomain.com:80/myPage.htm

into a port number and fails because it cannot convert the 
above to an integer.

That is the bug, but my guess is that there is more to it 
than that. 

The bigger question may be: Can I use httplib to 
authenticate into a secure NT-based web application?

Thank you!

Keyton

P.S. Here is a link to some more information. If it turns 
out to be a feature request and one you are interested in, 
I would be happy to help:

http://squid.sourceforge.net/ntlm/faq.html

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-03 04:41

Message:
Logged In: YES 
user_id=21627

What is NTLM? What is the bug you are reporting?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=538582&group_id=5470



From noreply@sourceforge.net  Sun May 19 02:25:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 May 2002 18:25:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-532467 ] 6.9 The raise statement is confusing
Message-ID: <E179FRZ-0003DL-00@usw-sf-web1.sourceforge.net>

Bugs item #532467, was opened at 2002-03-20 08:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick K. O'Brien (pobrien)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 6.9 The raise statement is confusing

Initial Comment:
The description supplied for "6.9 The raise statement" 
is confusing. In particular, it starts by explaining 
the intent of each "expresssion" and midway switches 
to "object" instead of expression. In particular, I 
can't make heads or tails out of the following passage:

"If the first object is a string, it then raises the 
exception identified by the first object, with the 
second one (or None) as its parameter. If the first 
object is a class or instance, it raises the exception 
identified by the class of the instance determined in 
the previous step, with the instance as its parameter."

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 20:25

Message:
Logged In: YES 
user_id=80475

Thanks Patrick.

Since I'm the new guy, I'll defer additional changes to 
Fred.  My patch style is to make the least invasive change 
that improves clarity and accuracy.  

Also, this may be a case where additional wording, even if 
informative and accurate, may detract from a strong 
understanding of how raise works.  

This section's cyclomatic complexity (nested if/elif/else 
paths) already impinges its understandability.

----------------------------------------------------------------------

Comment By: Patrick K. O'Brien (pobrien)
Date: 2002-05-16 09:34

Message:
Logged In: YES 
user_id=179604

Raymond, I really appreciate your patches. The big patch is 
terrific and gets my vote. I do have one more request for 
clarification in what you wrote. You say:

"If the first expression is a class object, it raises the 
exception identified by the class of an instance determined 
by the second expression.  If the second expression is an 
instance, that instance is used."

So we're talking about the form: raise class, instance

What I'm picturing is a situation where the second 
expression is an instance of a class other than the class 
object used as the first expression. Is this allowed, 
disallowed, allowed but nonsensical or allowed because it 
offers some practical benefit that I'm just not grasping?

I found and read the essay on "Standard Exception Classes 
in Python 1.5" 
(http://www.python.org/doc/essays/stdexceptions.html) and I 
can see that much was done to maintain backward 
compatibility. and apparently the "raise class, instance" 
form goes back quite a ways. Is this just a wart to be 
avoided? I'm probably expecting too much to expect the 
language reference to distinguish between what is strictly 
allowed vs. why it is allowed and whether it should even be 
used at all. It's just that the more I dug into this the 
more confused I became. I think I'm understanding the 
situation now.

In any case, make of this what you will. The bottom line is 
that your batch is definitely an improvement and I greatly 
appreciate your time and effort on this. Thanks.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 23:10

Message:
Logged In: YES 
user_id=80475

Attached two alternative patches.

The first makes minimal changes to achieve a clear and 
consistent use of "objects" versus "expressions".

The second alternative re-paragraphs the text and uses 
parallel sentence contruction to provide (IMHO) 
greater clarity without getting a headache reading it.

If accepted, please re-assign to Raymond for a commit to 
2.3 and to release22-maint.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470



From noreply@sourceforge.net  Sun May 19 02:56:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 May 2002 18:56:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
Message-ID: <E179FwG-0002Q9-00@usw-sf-web3.sourceforge.net>

Bugs item #557704, was opened at 2002-05-18 12:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Nobody/Anonymous (nobody)
Summary: netrc module can't handle all passwords

Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails.  Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:

machine piet.puk.com  	login foo 	password bar!

Additionally, entries in netrc may not have a login
name (e.g., for mail servers).  These entries should be
silently skipped. An example of a line that fails:

machine mail          password fruit

The included diff is a partial solution.  It allows all
ASCII punctuation characters to be used in passwords. 
Non-ASCII characters should probably also be allowed.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 20:56

Message:
Logged In: YES 
user_id=80475

Expanding keyspace is generally a good idea; however, the 
significance of meta-characters is bound to bite someone in 
the behind with a hard to find error.  So, please 
reconsider single-quote, double-quote, backslash, 
greaterthan, lessthan, and pipe.

Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in 
the character list

Looking at the second part of the patch, I don't follow (am 
perhaps being daft) why expanding the keyspace necessitates 
changing the login logic.

The idea of allowing non-ASCII characters would be cool if 
the world had already universally accepted Latin-1 coding.  
That conflict is the reason that site.py defaults to ASCII 
encoding instead of handling non-US codings out of the box.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470



From noreply@sourceforge.net  Sun May 19 21:50:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 May 2002 13:50:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-558072 ] faqwiz.py could do email obfuscation
Message-ID: <E179XdL-00088i-00@usw-sf-web4.sourceforge.net>

Bugs item #558072, was opened at 2002-05-19 17:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558072&group_id=5470

Category: Demos and Tools
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Reis (kiko_async)
Assigned to: Nobody/Anonymous (nobody)
Summary: faqwiz.py could do email obfuscation

Initial Comment:
Faqwiz.py could obfuscate emails very easily, simply by
replacing @ by some other symbol in it's output. I've
homecooked a solution that basically involves:

adding to faqconf.py:

 # Obfuscate @ symbol as

 OBFUSCATE="-at-"

and changing interpolate() in faqwiz.py:

 def _interpolate(format, args, kw):
    try:
        quote = kw['_quote']
    except KeyError:
        quote = 1 
    d = (kw,) + args + (faqconf.__dict__,)
    m = MagicDict(d, quote)
    return string.replace(format % m, '@', OBFUSCATE)

This isn't my favourite solution, though, but since I
find the code a bit hard to follow, it suffices for
now. I'm willing to work a bit more on this if it
interests people.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558072&group_id=5470



From noreply@sourceforge.net  Mon May 20 04:12:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 May 2002 20:12:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-558153 ] Compile error _sre.c on Cray T3E
Message-ID: <E179dbX-0003fj-00@usw-sf-web4.sourceforge.net>

Bugs item #558153, was opened at 2002-05-20 15:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558153&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hadfield (hadfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compile error _sre.c on Cray T3E

Initial Comment:
Building version 2.2.1 on a Cray T3E, compilation fails
on  _sre.c because it the name of a function (join)
clashes with a declaration in a system header
(unistd.h). Operating system is UNICOS/mk--sorry I
can't find out OS version number right now.

Solution is to rename the join function in _sre.c.
Patch is attached.

See thread entitled "Building Python on Cray T3E", 9-18
May 2002, on comp.lang.python.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558153&group_id=5470



From noreply@sourceforge.net  Mon May 20 04:17:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 May 2002 20:17:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-558153 ] Compile error _sre.c on Cray T3E
Message-ID: <E179dfg-0003lU-00@usw-sf-web1.sourceforge.net>

Bugs item #558153, was opened at 2002-05-20 15:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558153&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hadfield (hadfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compile error _sre.c on Cray T3E

Initial Comment:
Building version 2.2.1 on a Cray T3E, compilation fails
on  _sre.c because it the name of a function (join)
clashes with a declaration in a system header
(unistd.h). Operating system is UNICOS/mk--sorry I
can't find out OS version number right now.

Solution is to rename the join function in _sre.c.
Patch is attached.

See thread entitled "Building Python on Cray T3E", 9-18
May 2002, on comp.lang.python.

----------------------------------------------------------------------

>Comment By: Mark Hadfield (hadfield)
Date: 2002-05-20 15:17

Message:
Logged In: YES 
user_id=227147

Attempts to attach patch failed. Here it is:

*** /home/skip/tmp/_sre.c.~2.79~        Thu May  9 23:50:23 2002
--- /home/skip/tmp/_sre.c       Thu May  9 23:50:23 2002
***************
*** 1788,1794 ****
  #endif
  
  static PyObject*
! join(PyObject* list, PyObject* pattern)
  {
      /* join list elements */
  
--- 1788,1794 ----
  #endif
  
  static PyObject*
! join_list(PyObject* list, PyObject* pattern)
  {
      /* join list elements */
  
***************
*** 2241,2247 ****
      Py_DECREF(filter);
  
      /* convert list to single string (also removes list) */
!     item = join(list, self->pattern);
  
      if (!item)
          return NULL;
--- 2241,2247 ----
      Py_DECREF(filter);
  
      /* convert list to single string (also removes list) */
!     item = join_list(list, self->pattern);
  
      if (!item)
          return NULL;



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558153&group_id=5470



From noreply@sourceforge.net  Mon May 20 05:48:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 May 2002 21:48:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E179f6K-0004cn-00@usw-sf-web4.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-05-20 00:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 20:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 17:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470



From noreply@sourceforge.net  Mon May 20 06:34:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 May 2002 22:34:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-558166 ] Shutwown of IDLE blows up
Message-ID: <E179foE-00054R-00@usw-sf-web4.sourceforge.net>

Bugs item #558166, was opened at 2002-05-20 05:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558166&group_id=5470

Category: IDLE
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip Ruggera (pruggera)
Assigned to: Nobody/Anonymous (nobody)
Summary: Shutwown of IDLE blows up

Initial Comment:
When I shut down IDLE on Windows 2000 Professional 
running Python 2.2.1 I get a popup with "TclNotifier: 
pythonw.exe - Application Error" in the name bar 
and "The instruction at "0x77fcb144" referenced memory 
at "0x00b3300010". The memory could not be "read"."  
in the message box.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558166&group_id=5470



From noreply@sourceforge.net  Mon May 20 08:37:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 00:37:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-558179 ] rfc822.Message.get() incompatibility
Message-ID: <E179hjp-0006NP-00@usw-sf-web1.sourceforge.net>

Bugs item #558179, was opened at 2002-05-20 07:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558179&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: KAJIYAMA, Tamito (kajiyama)
Assigned to: Nobody/Anonymous (nobody)
Summary: rfc822.Message.get() incompatibility

Initial Comment:
There is a backward incompatibility with Message.get()
in the standard rfc822 module.  I don't believe this 
incompatibility is intended to be introduced, so here
is a bug report.

In Python 2.2 and later, Message.get("foo") returns
an empty string if the header field "foo" is not
defined.  In older versions of Python, on the other
hand, it returns None.

In fact, the definition of the method is duplicated
in the Message class in in Python 2.2 and later, as
follows:

class Message:

    def getheader(self, name, default=None):
        ...
    get = getheader

    ...

    def get(self, name, default="")
        ...

A possible fix would be to omit the later definition.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558179&group_id=5470



From noreply@sourceforge.net  Mon May 20 12:17:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 04:17:41 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-558238 ] Pickling bound methods
Message-ID: <E179lAb-0000Ml-00@usw-sf-web4.sourceforge.net>

Feature Requests item #558238, was opened at 2002-05-20 11:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=558238&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pickling bound methods

Initial Comment:
Last week I noticed that the pickle and cPickle modules
cannot handle bound methods. I found a solution that is
simple and (I think) general, so perhaps it should
become part of the standard library.

Here is my code:

import copy_reg

def pickle_bound_method(method):
    return getattr, (method.im_self, method.__name__)

class _Foo:
    def bar(self):
        pass

_foo = _Foo()

copy_reg.constructor(getattr)
copy_reg.pickle(type(_foo.bar), pickle_bound_method)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=558238&group_id=5470



From noreply@sourceforge.net  Mon May 20 12:55:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 04:55:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-558249 ] softspace vs --disable-unicode
Message-ID: <E179llV-0008CS-00@usw-sf-web2.sourceforge.net>

Bugs item #558249, was opened at 2002-05-20 11:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558249&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: softspace vs --disable-unicode

Initial Comment:
>>> print [], "f"
[]f

seems to happen for all non string types.  Will start
digging later.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558249&group_id=5470



From noreply@sourceforge.net  Mon May 20 14:51:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 06:51:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-558278 ] unittest.TestResult documentation
Message-ID: <E179nZQ-00025a-00@usw-sf-web4.sourceforge.net>

Bugs item #558278, was opened at 2002-05-20 05:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558278&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Stéphane Bidoul (sbidoul)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: unittest.TestResult documentation

Initial Comment:
The documentation of unittest.TestResult states:

<snip>
TestResult instances have the following attributes 
that will be of interest when inspecting the 
results of running a set of tests: 

errors 

A list containing pairs of TestCase instances and 
the sys.exc_info() results for tests which raised 
an exception but did not signal a test failure. 

failures 

A list containing pairs of TestCase instances and 
the sys.exc_info() results for tests which 
signalled a failure in the code under test. 
</snip>

unittest.py (version 1.14) has, in the docstring of 
TestResult:

<snip>
Each instance holds the total number of tests run, and 
collections of failures and errors that occurred among 
those test runs. The collections contain tuples of 
(testcase, exceptioninfo), where exceptioninfo is the 
*formatted* traceback of the error that occurred.
</snip>

So the second parts of the errors and failures lists 
of pairs are actually strings and not sys.exc_info() 
tuples. The docstring in the code looks correct to me, 
so I guess the documentation needs to be fixed. Note 
that this behaviour changed between python 2.1 and 
python 2.2. 

As a side note, I noticed the problem because I had a 
custom test runner that exploited the traceback 
information to customize the display of results based 
on the actual failureException subclass. I overcame 
that by maintaining my own errors and failure lists in 
a subclass of TestResult. 

Now, I've read the rationale for keeping only 
formatted tracebacks, but this kind of use of the 
traceback for customized result display looked useful 
to me. May be there is a better way?

Regards.

-Stephane


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558278&group_id=5470



From noreply@sourceforge.net  Mon May 20 14:52:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 06:52:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-558279 ] \verbatiminput and name duplication
Message-ID: <E179nZw-00013x-00@usw-sf-web2.sourceforge.net>

Bugs item #558279, was opened at 2002-05-20 09:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558279&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: \verbatiminput and name duplication

Initial Comment:
The \verbatiminput support which generates file names
for the "Download as text" feature does not check that
the source file names are unique without the extension.
 If a document uses \verbatiminput with two files,
sample.py and sample.html, both get written to the
output as sample.txt; last one processed wins.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558279&group_id=5470



From noreply@sourceforge.net  Mon May 20 14:57:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 06:57:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-558249 ] softspace vs --disable-unicode
Message-ID: <E179nem-0001YM-00@usw-sf-web3.sourceforge.net>

Bugs item #558249, was opened at 2002-05-20 11:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558249&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
>Assigned to: Michael Hudson (mwh)
Summary: softspace vs --disable-unicode

Initial Comment:
>>> print [], "f"
[]f

seems to happen for all non string types.  Will start
digging later.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-05-20 13:57

Message:
Logged In: YES 
user_id=6656

Well, that went easily enough.

Fixed in revision 2.311 pf ceval.c.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558249&group_id=5470



From noreply@sourceforge.net  Mon May 20 16:15:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 08:15:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-558279 ] \verbatiminput and name duplication
Message-ID: <E179ot5-0001vU-00@usw-sf-web2.sourceforge.net>

Bugs item #558279, was opened at 2002-05-20 09:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558279&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: \verbatiminput and name duplication

Initial Comment:
The \verbatiminput support which generates file names
for the "Download as text" feature does not check that
the source file names are unique without the extension.
 If a document uses \verbatiminput with two files,
sample.py and sample.html, both get written to the
output as sample.txt; last one processed wins.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-20 11:15

Message:
Logged In: YES 
user_id=3066

I'm attaching a patch that will at least make sure things
work when presented with source filenames that share the
same base name, or are the same file included more than once.

The patch is not ideal:  repeated inclusions are not
detected, so the content will be duplicated for each
inclusion (minor).  The filename generation does not ensure
that a source file's basename will ever be used for a file
with that basename.  For example, including sample.py,
sample.c, and sample-c.c, in that order, will generate the
file names sample.txt, sample-c.txt, and sample-c-c.txt.

Note that filename re-writing is needed to ensure that Web
servers produce the text/plain Content-Type for these files;
there is no reliable way to configure Web servers to produce
 the appropriate headers from the content space.  (We also
need to avoid allowing the output text files to have
extensions of .html since LaTeX2HTML or node2label.pl might
overwrite them.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558279&group_id=5470



From noreply@sourceforge.net  Mon May 20 16:43:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 08:43:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E179pJt-0003Ky-00@usw-sf-web1.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 11:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 00:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 20:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 17:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470



From noreply@sourceforge.net  Mon May 20 16:53:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 08:53:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-558279 ] \verbatiminput and name duplication
Message-ID: <E179pT4-0002n5-00@usw-sf-web3.sourceforge.net>

Bugs item #558279, was opened at 2002-05-20 09:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558279&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: \verbatiminput and name duplication

Initial Comment:
The \verbatiminput support which generates file names
for the "Download as text" feature does not check that
the source file names are unique without the extension.
 If a document uses \verbatiminput with two files,
sample.py and sample.html, both get written to the
output as sample.txt; last one processed wins.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-20 11:53

Message:
Logged In: YES 
user_id=3066

I've added an improved patch that only creates one output
file for each input file, no matter how many times it's
input.  The "Download as text" message in the footer is also
modified to include the original filename if the actual
filename has been modified from the original (which it
always has been unless the original extension was .txt).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-20 11:15

Message:
Logged In: YES 
user_id=3066

I'm attaching a patch that will at least make sure things
work when presented with source filenames that share the
same base name, or are the same file included more than once.

The patch is not ideal:  repeated inclusions are not
detected, so the content will be duplicated for each
inclusion (minor).  The filename generation does not ensure
that a source file's basename will ever be used for a file
with that basename.  For example, including sample.py,
sample.c, and sample-c.c, in that order, will generate the
file names sample.txt, sample-c.txt, and sample-c-c.txt.

Note that filename re-writing is needed to ensure that Web
servers produce the text/plain Content-Type for these files;
there is no reliable way to configure Web servers to produce
 the appropriate headers from the content space.  (We also
need to avoid allowing the output text files to have
extensions of .html since LaTeX2HTML or node2label.pl might
overwrite them.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558279&group_id=5470



From noreply@sourceforge.net  Mon May 20 22:32:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 14:32:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-558166 ] Shutdown of IDLE blows up
Message-ID: <E179uly-00079N-00@usw-sf-web4.sourceforge.net>

Bugs item #558166, was opened at 2002-05-20 05:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558166&group_id=5470

Category: IDLE
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip Ruggera (pruggera)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Shutdown of IDLE blows up

Initial Comment:
When I shut down IDLE on Windows 2000 Professional 
running Python 2.2.1 I get a popup with "TclNotifier: 
pythonw.exe - Application Error" in the name bar 
and "The instruction at "0x77fcb144" referenced memory 
at "0x00b3300010". The memory could not be "read"."  
in the message box.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558166&group_id=5470



From noreply@sourceforge.net  Tue May 21 00:47:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 16:47:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 installs shared libs with mode 0700
Message-ID: <E179wrt-00008r-00@usw-sf-web4.sourceforge.net>

Bugs item #425007, was opened at 2001-05-17 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Michael Hudson (mwh)
Summary: Python 2.1 installs shared libs with mode 0700

Initial Comment:
I have gone back and tried Python 1.6 and 2.0.  Both
work fine.  When I install Python 2.1, everything is
broken.  The problem is that when a module is a shared
library (.so), python refuses to load the module.  Example:

import os
import sys
import SocketServer

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/SocketServer.py", line 126, in ?
    import socket
  File "/usr/lib/python2.1/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket

Now, do a "locate _socket.so" and I get:
/usr/lib/python2.1/site-packages/_socket.so
/usr/lib/python2.1/lib-dynload/_socket.so


Clearly they are there, it's just that Python refuses
to load them.


I made Python 2.1 from source as fetched from the 2.1
tar ball.  It makes cleanly.  During the installation,
I see some items that I believe to be minor that popup,
but don't currectly expect that they are the problem. 
I have tried many times using different configure
options to get this to work, deleting the previous
installation each time.  I've even tried installing in
different locations.

As is, Python 2.1 is completely broken for me.  Surely
I'm not the only one having this problem, especially
since 1.5, 1.6, and 2.0 all work correctly.

Any help would be great.  BTW, doing a "print sys.path"
gives me: ['', '/usr/lib/python2.1',
'/usr/lib/python2.1/plat-linux2',
'/usr/lib/python2.1/lib-tk',
'/usr/lib/python2.1/lib-dynload',
'/usr/lib/python2.1/site-packages']

As you can see, lib-dynload is in the path, so I'm not
really sure what's going on.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-20 16:47

Message:
Logged In: NO 

Found a similar problem on Mac OS X's command line installation of Python 2.2.1.  Darwin kernel 5.4 OS X 10.1.4.  Apple's gcc 2.95.2.

Built as regular user, umask 077.  Ran make install as root, umask 022.  All files in /usr/local/lib/python-2.2/lib-dynload were mode 711, which is not sufficient for python to load them.  Same error as this problem "ImportError: No module named time".  Error is clearer when viewed as:

>>> help()
help> modules time
[Traceback redacted for brevity]
IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.2/lib-dynload/MacOS.so'

Suggest you add a comment on this to the README's Troubleshooting section.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-01-16 06:28

Message:
Logged In: YES 
user_id=6656

I'll do something about this at some point.

Using copy_tree to install shared libraries is gross.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-21 23:24

Message:
Logged In: YES 
user_id=149084

INSTALLATION:  Confirm. Built with umask 077, group and
others have no permissions in source tree. (Note that if I
su to install, the 077 follows! ok, install with umask of
022, normal for root.). Everything in installation looks ok
except for lib-dynload, which has 700 permissions on files.
No _socket.so in site-packages. 

REINSTALLATION:  I suspect there is more to this than
distutils...Redo the build with umask 022.  Then chmod the
whole previously installed tree to 700 and if you then
repeat the install on top of it you find that while the .py
files have been correctly copied by /usr/bin/install with
644, the .pyc and .pyo are still 700 though recompiled. 
This also happens in 1.5.2.  The lib-dynload files are 755.
This is with a umask of 022 for both the build user and
root. Finally, delete a few files from lib-dynload, chmod
the rest to 700, and make install again! The deleted files
are restored at 755, the rest stay at 700. In general,
messed up permissions are not fixed by a re-install.

It would seem desirable that re-installing should result in
exactly the same install tree as the initial install,
including permissions, except that any non-distribution
files (e.g. "site-packages") added by the user would be
unaffected.  If the user had modified some distribution .py
files they would be reverted by the re-install, which does
seem to be the case. A broken installation could be repaired
by re-installing.

Would that be a reasonable policy? Or is it too difficult to
fix up all the permissions? A compromise might be to delete
the .pyo .pyc before compiling, and explicitly chmod all the
lib-dynload files during install.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:15

Message:
Logged In: YES 
user_id=11375

Reclassifying as a Distutils bug.  

The install_lib subcommand simply copies the contents of 
the BUILD/ tree.  It needs to pointedly ignore the umask 
and set the proper permissions on the installed files.
  


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:32

Message:
Logged In: YES 
user_id=6380

Assigning this to Andrew -- clearly the setup.py script (or
distutils) needs to be fixed to fix this.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:24

Message:
Logged In: YES 
user_id=6380

I didn't mean to imply that you did something incorrectly. 
I just meant that there was some interaction between your
system and Python that didn't work out the way it was
supposed to be. Since Python installs correctly on most
systems, I was implying that there's something unusual in
your system that the Python install procedure doesn't
anticipate.

The mode 0700 for the shared libraries is a big hint at what
was wrong (and if you had done an ls -l of the file when
first reporting this we would have figured out the problem
much quicker). Is perhaps the umask of the user who built
(not installed) the files set to 077? In that case, the
cause is that the "make install" by root doesn't change the
file modes to something more reasonable (I've confirmed that
this indeed happens). I'll look into whether this can be
fixed. I'm changing the subject line of this bug report to
reflect more accurately that the problem is with the file
modes of shared libs.

I still believe that the _socket.so in site-packages could
not have been placed there by the normal Python install
procedure.


----------------------------------------------------------------------

Comment By: Greg Copeland (oracle)
Date: 2001-05-21 08:13

Message:
Logged In: YES 
user_id=40173

The problem is that the installation is partially broken. It
didn't install the shared libraries with proper permissions.
When Python installed the shared libs, it installed the libs
as root.root having 0700 permissions. When I tried to
execute it as a normal user, obviously, it fails to load the
shared lib. Python then, incorrectly reports that the shared
lib can not be found.  Of course, the correct solution is
for Python to accurately report the problem and to have the
installation always install the libraries with correct
ownership and permission.  I don't think I'm asking for too
much here.  Seems pretty reasonable to me.

Anyone stating that I did not install correctly is woefully
incorrect. Simply put, the installation is not 100%. As for
some of the libraries existing twice. Well, simply put, the
installation is not 100%.

At any rate, I think it's safe to close this bug but we
might want to add it to the faq-o-matic somewhere or some
such thing.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-20 10:35

Message:
Logged In: YES 
user_id=6380

Clearly it's something you have done to yourself. :-)  The
question is how to find out what.

Try "python -v" or even "python -vv" and see what it prints
when you try to import _socket. This should give you some
clues (it shows where it searches for modules during
import).

As kbk says, that other _socket.so is mysterious.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-19 17:16

Message:
Logged In: YES 
user_id=149084

Well, import SocketServer works ok for me with Python built
both from the 2.1 tar file and the 2.2a0 CVS tree. I'm
running Linux 2.2.5 (RH 6.2) on Pentium.

Did you make clean after changing the configure options?

It is not normal to have _socket.so in .../site-packages; it
should be only in .../lib-dynload.  Default installation has
only the README file in site-packages.

Your sys.path looks normal, except that Python default
installs at /usr/local/[bin/lib].  I tried a build targeted
at /usr/[bin/lib] and it was ok.

You could try make clobber, but it's almost as fast to start
over. Try a vanilla installation:
1. delete your install tree @ /usr/local/lib/python2.1
(and/or /usr/lib)
2. delete your source tree from wherever you unpacked the
tar file.
3. untar again, cd to source directory it created
4. without changing any files, and no configure options, run
./configure, then make, then make install

If that doesn't help, what Linux are you running, on what
box, and where did you get your 2.1 tar file?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470



From noreply@sourceforge.net  Tue May 21 01:18:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 17:18:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC& broken
Message-ID: <E179xMa-0000lb-00@usw-sf-web1.sourceforge.net>

Bugs item #558488, was opened at 2002-05-20 19:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: DL_EXPORT on VC& broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Tue May 21 01:19:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 17:19:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-558488 ] DL_EXPORT on VC7 broken
Message-ID: <E179xMp-0000ly-00@usw-sf-web1.sourceforge.net>

Bugs item #558488, was opened at 2002-05-20 19:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: David Aldridge (daldridge)
Assigned to: Nobody/Anonymous (nobody)
>Summary: DL_EXPORT on VC7 broken

Initial Comment:
Extension modules (_sre, _socket, etc.) do not have 
their entry points exported correctly when building 
Python (2.1 onwards) with Microsoft Visual C++ 7 
(part of Visual Studio .NET).  (NOTE: Everything 
compiles and links without errors.  It's just the 
exports that are missing.)

Think through the prepocessor flow when compiling 
_sre.c, for example, the following happens (this is 
from memory so please excuse inaccuracies):

1) _sre.c #includes "python.h"

2) "python.h" pretty much immediatly 
#includes "config.h"

3) "config.h" has the following:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

4) USE_DL_EXPORT is NOT defined (and cannot be in the 
_sre project, or it will not import pythoncore's (?) 
exports), thus DL_EXPORT is not yet defined.

5) After preprocessing "config.h", we're back 
in "python.h", which has a block:

#ifndef DL_EXPORT
#define DL_EXPORT(RTYPE) RTYPE
#endif

6) Back in _sre.c, the extension module entry point 
is:

DL_EXPORT(void) init_sre()

This expands to

void init_sre()

And thus does not get exported.



If I change the "config.h" block above to be:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

(ie. add the DL_EXPORT line if/when USE_DL_IMPORT is 
defined), everything works correctly.  Not 
guaranteeing this is the "correct" solution, but it 
seems to work.

My specific test case was to build everything, run 
python.exe from the command line, then 
attempt "import re".

This results in a Traceback with "ImportError: 
dynamic module does not define init function 
(init_sre)".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558488&group_id=5470



From noreply@sourceforge.net  Tue May 21 03:51:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 19:51:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E179zk8-0001Q9-00@usw-sf-web3.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-05-20 22:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 11:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 00:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 20:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 17:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470



From noreply@sourceforge.net  Tue May 21 04:11:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 20:11:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-506647 ] random.cunifvariate() incorrect?
Message-ID: <E17A03A-0001Jz-00@usw-sf-web2.sourceforge.net>

Bugs item #506647, was opened at 2002-01-21 16:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506647&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Maciej Kalisiak (abcdefghijklmno)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: random.cunifvariate() incorrect?

Initial Comment:
random.cunifvariate() currently is defined as:
  return (mean + arc * (self.random() - 0.5)) % _pi

First of all, this returns values in the range [0, pi)
due to the modulus, which really makes it a
semi-circular distribution, not circular (but I'm not a
mathie, so perhaps I'm wrong).

I think the normalizing step ("% _pi", or whatever this
gets changed to) should probably be mentioned in the
documentation for this function; it caught me by
surprise, and I expect it will catch some others too.  

With this defintion, the function returns a random
value in the range [mean-arc/2, mean+arc/2).  The docs
say that arc, like mean, can only be in the range
[0,pi].  This would imply that one cannot get values in
the other half of the circle, i.e. [pi, 2*pi).  Since
there doesn't seem to be anything stopping the caller
from using an arc in [0,2*pi], perhaps the
documentation should be updated?


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-05-20 23:11

Message:
Logged In: YES 
user_id=31435

I recommend to deprecate this function instead of "fixing" 
it.  If we deprecate it in 2.3, we can lose it entirely for 
2.4.  The function appears useless to me with or without 
the suggested fixes, and anyone who *did* want 
something "like this" would just call random.uniform() 
passing appropriate bounds anyway.  Indeed, Raymond's patch 
amounts to making cunifvariate a synonym for calling 
random.uniform(mean-arc/2, mean+arc/2).  We don't need a 
separate function for something so trivial.

BTW, I've never seen the word "cunifvariate" outside of 
Python's random module.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 07:00

Message:
Logged In: YES 
user_id=21627

I'm not qualified to comment on the correctness of this
change, so unassigning it. Maybe Tim knows what a
cunifvariate is?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 17:53

Message:
Logged In: YES 
user_id=80475

Martin, please approve the patch and I'll load it for Py2.3.

The docs don't match the function and the actual behavior 
is weird.  Thinking in degrees, calling with a mean of 175 
and an arc of 20 returns {x | 0<x<5 or 165<x<180} with an 
expected mean of 130 instead of the specified mean of 175.

Google reports no non-Python examples of cunifvariate so 
there is no standard to match against.

The patch removes the Pi normalization in the 
implementation and removes the superfluous domain 
restriction in the docs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506647&group_id=5470



From noreply@sourceforge.net  Tue May 21 04:27:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 20:27:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-506647 ] random.cunifvariate() incorrect?
Message-ID: <E17A0JN-0001m8-00@usw-sf-web3.sourceforge.net>

Bugs item #506647, was opened at 2002-01-21 16:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506647&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Maciej Kalisiak (abcdefghijklmno)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.cunifvariate() incorrect?

Initial Comment:
random.cunifvariate() currently is defined as:
  return (mean + arc * (self.random() - 0.5)) % _pi

First of all, this returns values in the range [0, pi)
due to the modulus, which really makes it a
semi-circular distribution, not circular (but I'm not a
mathie, so perhaps I'm wrong).

I think the normalizing step ("% _pi", or whatever this
gets changed to) should probably be mentioned in the
documentation for this function; it caught me by
surprise, and I expect it will catch some others too.  

With this defintion, the function returns a random
value in the range [mean-arc/2, mean+arc/2).  The docs
say that arc, like mean, can only be in the range
[0,pi].  This would imply that one cannot get values in
the other half of the circle, i.e. [pi, 2*pi).  Since
there doesn't seem to be anything stopping the caller
from using an arc in [0,2*pi], perhaps the
documentation should be updated?


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 22:27

Message:
Logged In: YES 
user_id=80475

So be it.  

If there are no objections received before Thursday May 
24th, I'll deprecate it.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 22:11

Message:
Logged In: YES 
user_id=31435

I recommend to deprecate this function instead of "fixing" 
it.  If we deprecate it in 2.3, we can lose it entirely for 
2.4.  The function appears useless to me with or without 
the suggested fixes, and anyone who *did* want 
something "like this" would just call random.uniform() 
passing appropriate bounds anyway.  Indeed, Raymond's patch 
amounts to making cunifvariate a synonym for calling 
random.uniform(mean-arc/2, mean+arc/2).  We don't need a 
separate function for something so trivial.

BTW, I've never seen the word "cunifvariate" outside of 
Python's random module.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 06:00

Message:
Logged In: YES 
user_id=21627

I'm not qualified to comment on the correctness of this
change, so unassigning it. Maybe Tim knows what a
cunifvariate is?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 16:53

Message:
Logged In: YES 
user_id=80475

Martin, please approve the patch and I'll load it for Py2.3.

The docs don't match the function and the actual behavior 
is weird.  Thinking in degrees, calling with a mean of 175 
and an arc of 20 returns {x | 0<x<5 or 165<x<180} with an 
expected mean of 130 instead of the specified mean of 175.

Google reports no non-Python examples of cunifvariate so 
there is no standard to match against.

The patch removes the Pi normalization in the 
implementation and removes the superfluous domain 
restriction in the docs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506647&group_id=5470



From noreply@sourceforge.net  Tue May 21 04:37:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 May 2002 20:37:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17A0SN-0001am-00@usw-sf-web2.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 11:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Neal Norwitz (nnorwitz)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 22:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 21:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 10:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-19 23:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 19:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 15:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 15:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 19:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 17:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470



From noreply@sourceforge.net  Tue May 21 13:52:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 05:52:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17A97u-0007uk-00@usw-sf-web3.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Neal Norwitz (nnorwitz)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 08:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 23:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 22:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 11:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 00:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 20:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 17:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470



From noreply@sourceforge.net  Tue May 21 13:59:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 05:59:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17A9EL-0000Fe-00@usw-sf-web4.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 11:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Neal Norwitz (nnorwitz)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 07:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 07:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 22:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 21:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 10:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-19 23:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 19:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 15:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 15:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 19:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 17:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470



From noreply@sourceforge.net  Tue May 21 16:42:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 08:42:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-533291 ] __reduce__ does not work as documented
Message-ID: <E17ABmo-0001Vf-00@usw-sf-web3.sourceforge.net>

Bugs item #533291, was opened at 2002-03-21 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: __reduce__ does not work as documented

Initial Comment:
The documentation for __reduce__ says that the second
element of the returned tuple can either be a tuple
of arguments or None.  The copy module does not handle
the None case:

  class C(object):
    def __reduce__(self):
        return (C, None)

  import copy
  copy.copy(C())



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-21 11:42

Message:
Logged In: YES 
user_id=3066

Issues with the doc portion the patch:

- "/deprecated" should be spelled "\deprecated"

- Deprecations are whole paragraphs; don't include them
  inside parenthetical expressions.  Make them separate
  paragraphs which preceed or succeed the relevant
  material in the documentation.

Once appropriate corrections are made, I'm fine with the patch.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 23:14

Message:
Logged In: YES 
user_id=80475

See attached documentation and code patch for deprecating 
the None version.  If approved, re-assign to Raymond for 
commit.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:36

Message:
Logged In: YES 
user_id=6380

So be it.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 12:09

Message:
Logged In: YES 
user_id=35752

I would prefer that the None version be deprecated.  The
documentation for __reduce__ is confusing enough as it is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 11:59

Message:
Logged In: YES 
user_id=6380

I'm not sure it's that simple. While pickling a C instance
indeed succeed, unpickling it raises a strange exception:

>>> pickle.loads(pickle.dumps(C()))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/guido/trunk/Lib/pickle.py", line 982, in loads
    return Unpickler(file).load()
  File "/home/guido/trunk/Lib/pickle.py", line 593, in load
    dispatch[key](self)
  File "/home/guido/trunk/Lib/pickle.py", line 842, in
load_reduce
    value = callable.__basicnew__()
AttributeError: type object 'C' has no attribute
'__basicnew__'
>>>

It appears that an argument tuple of None signals some
special Jim-Fulton-only behavior. __basicnew__ is a feature
of ExtensionClasses (similar to __new__ in Python 2.2), and
while ExtensionClasses work in 2.2, they're being
deprecated: Zope 2.x will continue to use Python 2.1.x, and
Zope 3 will require Python 2.2 or higher.

The copy module has never worked for ExtensionClass
instances (unless maybe the class defines a __copy__
method).

Maybe the right thing to do is to document 'None' as a
special case that one shouldn't use, and deprecate
__basicnew__?

(Hm, OTOH why don't I just approve your fix so we can stop
thinking about this. :-)

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 10:10

Message:
Logged In: YES 
user_id=35752

Added trivial patch to fix copy.py module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470



From noreply@sourceforge.net  Tue May 21 17:10:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 09:10:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E17ACDd-0001Em-00@usw-sf-web2.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-21 12:10

Message:
Logged In: YES 
user_id=3066

The \deprecated markup should always be a separate paragraph
(or list item).  Please revise the doc patch and re-submit
for review.  (But thanks for working on this; the content is
good!)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 02:29

Message:
Logged In: YES 
user_id=80475

Fred, here's a doc patch.
Okay to commit and close this bug?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 08:37

Message:
Logged In: YES 
user_id=6380

Note: complex % is also being deprecated.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 21:42

Message:
Logged In: YES 
user_id=6380

Fred, can you fix the docs?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 21:36

Message:
Logged In: YES 
user_id=6380

OK, I'll add the deprecation warning.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-14 21:23

Message:
Logged In: YES 
user_id=31435

Heh.  divmod(c1, c2)[0] for complexes returns
  floor((c1/c2).real)
according to the Reference Manual (5.6 Binary arithmetic 
operations), and it looks like the code implements that 
just so.  The Library manual's "Builtin Functions" section 
only mentions ints, longs and floats, while the same 
manual's "2.2.4 Numeric Types" claims, in a footnote, 
that "Builtin Functions" told the full truth about divmod.

The primary lesson I take from this is that a .chm file is 
a truly wonderful way to search the docs <wink>.

I don't think divmod is useful for complexes, and would be 
happy to see it go away.  But I guess that means taking the 
full-blown deprecation path.

I note that the original complexobject.c didn't implement 
divmod.  The current divmod appears to derive from a patch 
contributed by Tim Hochberg, in rev 2.10 in 1996.  You 
(Guido) added a question mark to the checkin comment, so I 
figure it never made much sense to you either.

I agree floor divsion and divmod(...)[0] should do the same 
thing, whatever that is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:44

Message:
Logged In: YES 
user_id=6380

Hm. I believe that if divmod() returns something, // should
return the same thing (well, divmod()[0]). But what on earth
does divmod() do on two complex numbers??? Does it make
sense to have divmod() on complex at all? Assigned to Tim
for a ruling.

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 19:24

Message:
Logged In: YES 
user_id=112690

As suggested by Tim I'll upload here the patch and the test
for this bug.
The patch clears nb_true_divide entry and deletes the
complex_int_div function.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470



From noreply@sourceforge.net  Tue May 21 18:23:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 10:23:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-533291 ] __reduce__ does not work as documented
Message-ID: <E17ADMb-0003Ou-00@usw-sf-web4.sourceforge.net>

Bugs item #533291, was opened at 2002-03-21 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Raymond Hettinger (rhettinger)
Summary: __reduce__ does not work as documented

Initial Comment:
The documentation for __reduce__ says that the second
element of the returned tuple can either be a tuple
of arguments or None.  The copy module does not handle
the None case:

  class C(object):
    def __reduce__(self):
        return (C, None)

  import copy
  copy.copy(C())



----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 12:23

Message:
Logged In: YES 
user_id=80475

Committed libpickle.tex 1.36 and pickle.py 1.62.
Closing patch.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-21 10:42

Message:
Logged In: YES 
user_id=3066

Issues with the doc portion the patch:

- "/deprecated" should be spelled "\deprecated"

- Deprecations are whole paragraphs; don't include them
  inside parenthetical expressions.  Make them separate
  paragraphs which preceed or succeed the relevant
  material in the documentation.

Once appropriate corrections are made, I'm fine with the patch.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 22:14

Message:
Logged In: YES 
user_id=80475

See attached documentation and code patch for deprecating 
the None version.  If approved, re-assign to Raymond for 
commit.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:36

Message:
Logged In: YES 
user_id=6380

So be it.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 12:09

Message:
Logged In: YES 
user_id=35752

I would prefer that the None version be deprecated.  The
documentation for __reduce__ is confusing enough as it is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 11:59

Message:
Logged In: YES 
user_id=6380

I'm not sure it's that simple. While pickling a C instance
indeed succeed, unpickling it raises a strange exception:

>>> pickle.loads(pickle.dumps(C()))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/guido/trunk/Lib/pickle.py", line 982, in loads
    return Unpickler(file).load()
  File "/home/guido/trunk/Lib/pickle.py", line 593, in load
    dispatch[key](self)
  File "/home/guido/trunk/Lib/pickle.py", line 842, in
load_reduce
    value = callable.__basicnew__()
AttributeError: type object 'C' has no attribute
'__basicnew__'
>>>

It appears that an argument tuple of None signals some
special Jim-Fulton-only behavior. __basicnew__ is a feature
of ExtensionClasses (similar to __new__ in Python 2.2), and
while ExtensionClasses work in 2.2, they're being
deprecated: Zope 2.x will continue to use Python 2.1.x, and
Zope 3 will require Python 2.2 or higher.

The copy module has never worked for ExtensionClass
instances (unless maybe the class defines a __copy__
method).

Maybe the right thing to do is to document 'None' as a
special case that one shouldn't use, and deprecate
__basicnew__?

(Hm, OTOH why don't I just approve your fix so we can stop
thinking about this. :-)

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 10:10

Message:
Logged In: YES 
user_id=35752

Added trivial patch to fix copy.py module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470



From noreply@sourceforge.net  Tue May 21 18:46:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 10:46:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E17ADig-00030k-00@usw-sf-web3.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 08:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Raymond Hettinger (rhettinger)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 12:46

Message:
Logged In: YES 
user_id=80475

Separated the \deprecated sections.  Revised patch attached.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-21 11:10

Message:
Logged In: YES 
user_id=3066

The \deprecated markup should always be a separate paragraph
(or list item).  Please revise the doc patch and re-submit
for review.  (But thanks for working on this; the content is
good!)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 01:29

Message:
Logged In: YES 
user_id=80475

Fred, here's a doc patch.
Okay to commit and close this bug?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 07:37

Message:
Logged In: YES 
user_id=6380

Note: complex % is also being deprecated.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:42

Message:
Logged In: YES 
user_id=6380

Fred, can you fix the docs?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:36

Message:
Logged In: YES 
user_id=6380

OK, I'll add the deprecation warning.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-14 20:23

Message:
Logged In: YES 
user_id=31435

Heh.  divmod(c1, c2)[0] for complexes returns
  floor((c1/c2).real)
according to the Reference Manual (5.6 Binary arithmetic 
operations), and it looks like the code implements that 
just so.  The Library manual's "Builtin Functions" section 
only mentions ints, longs and floats, while the same 
manual's "2.2.4 Numeric Types" claims, in a footnote, 
that "Builtin Functions" told the full truth about divmod.

The primary lesson I take from this is that a .chm file is 
a truly wonderful way to search the docs <wink>.

I don't think divmod is useful for complexes, and would be 
happy to see it go away.  But I guess that means taking the 
full-blown deprecation path.

I note that the original complexobject.c didn't implement 
divmod.  The current divmod appears to derive from a patch 
contributed by Tim Hochberg, in rev 2.10 in 1996.  You 
(Guido) added a question mark to the checkin comment, so I 
figure it never made much sense to you either.

I agree floor divsion and divmod(...)[0] should do the same 
thing, whatever that is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 19:44

Message:
Logged In: YES 
user_id=6380

Hm. I believe that if divmod() returns something, // should
return the same thing (well, divmod()[0]). But what on earth
does divmod() do on two complex numbers??? Does it make
sense to have divmod() on complex at all? Assigned to Tim
for a ruling.

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 18:24

Message:
Logged In: YES 
user_id=112690

As suggested by Tim I'll upload here the patch and the test
for this bug.
The patch clears nb_true_divide entry and deletes the
complex_int_div function.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470



From noreply@sourceforge.net  Tue May 21 18:49:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 10:49:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E17ADlZ-0003jS-00@usw-sf-web4.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 08:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 12:46

Message:
Logged In: YES 
user_id=80475

Separated the \deprecated sections.  Revised patch attached.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-21 11:10

Message:
Logged In: YES 
user_id=3066

The \deprecated markup should always be a separate paragraph
(or list item).  Please revise the doc patch and re-submit
for review.  (But thanks for working on this; the content is
good!)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 01:29

Message:
Logged In: YES 
user_id=80475

Fred, here's a doc patch.
Okay to commit and close this bug?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 07:37

Message:
Logged In: YES 
user_id=6380

Note: complex % is also being deprecated.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:42

Message:
Logged In: YES 
user_id=6380

Fred, can you fix the docs?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:36

Message:
Logged In: YES 
user_id=6380

OK, I'll add the deprecation warning.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-14 20:23

Message:
Logged In: YES 
user_id=31435

Heh.  divmod(c1, c2)[0] for complexes returns
  floor((c1/c2).real)
according to the Reference Manual (5.6 Binary arithmetic 
operations), and it looks like the code implements that 
just so.  The Library manual's "Builtin Functions" section 
only mentions ints, longs and floats, while the same 
manual's "2.2.4 Numeric Types" claims, in a footnote, 
that "Builtin Functions" told the full truth about divmod.

The primary lesson I take from this is that a .chm file is 
a truly wonderful way to search the docs <wink>.

I don't think divmod is useful for complexes, and would be 
happy to see it go away.  But I guess that means taking the 
full-blown deprecation path.

I note that the original complexobject.c didn't implement 
divmod.  The current divmod appears to derive from a patch 
contributed by Tim Hochberg, in rev 2.10 in 1996.  You 
(Guido) added a question mark to the checkin comment, so I 
figure it never made much sense to you either.

I agree floor divsion and divmod(...)[0] should do the same 
thing, whatever that is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 19:44

Message:
Logged In: YES 
user_id=6380

Hm. I believe that if divmod() returns something, // should
return the same thing (well, divmod()[0]). But what on earth
does divmod() do on two complex numbers??? Does it make
sense to have divmod() on complex at all? Assigned to Tim
for a ruling.

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 18:24

Message:
Logged In: YES 
user_id=112690

As suggested by Tim I'll upload here the patch and the test
for this bug.
The patch clears nb_true_divide entry and deletes the
complex_int_div function.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470



From noreply@sourceforge.net  Tue May 21 18:54:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 10:54:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E17ADqS-00046P-00@usw-sf-web1.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-21 13:54

Message:
Logged In: YES 
user_id=3066

Thanks!  Go ahead and check it in.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 13:46

Message:
Logged In: YES 
user_id=80475

Separated the \deprecated sections.  Revised patch attached.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-21 12:10

Message:
Logged In: YES 
user_id=3066

The \deprecated markup should always be a separate paragraph
(or list item).  Please revise the doc patch and re-submit
for review.  (But thanks for working on this; the content is
good!)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 02:29

Message:
Logged In: YES 
user_id=80475

Fred, here's a doc patch.
Okay to commit and close this bug?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 08:37

Message:
Logged In: YES 
user_id=6380

Note: complex % is also being deprecated.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 21:42

Message:
Logged In: YES 
user_id=6380

Fred, can you fix the docs?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 21:36

Message:
Logged In: YES 
user_id=6380

OK, I'll add the deprecation warning.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-14 21:23

Message:
Logged In: YES 
user_id=31435

Heh.  divmod(c1, c2)[0] for complexes returns
  floor((c1/c2).real)
according to the Reference Manual (5.6 Binary arithmetic 
operations), and it looks like the code implements that 
just so.  The Library manual's "Builtin Functions" section 
only mentions ints, longs and floats, while the same 
manual's "2.2.4 Numeric Types" claims, in a footnote, 
that "Builtin Functions" told the full truth about divmod.

The primary lesson I take from this is that a .chm file is 
a truly wonderful way to search the docs <wink>.

I don't think divmod is useful for complexes, and would be 
happy to see it go away.  But I guess that means taking the 
full-blown deprecation path.

I note that the original complexobject.c didn't implement 
divmod.  The current divmod appears to derive from a patch 
contributed by Tim Hochberg, in rev 2.10 in 1996.  You 
(Guido) added a question mark to the checkin comment, so I 
figure it never made much sense to you either.

I agree floor divsion and divmod(...)[0] should do the same 
thing, whatever that is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:44

Message:
Logged In: YES 
user_id=6380

Hm. I believe that if divmod() returns something, // should
return the same thing (well, divmod()[0]). But what on earth
does divmod() do on two complex numbers??? Does it make
sense to have divmod() on complex at all? Assigned to Tim
for a ruling.

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 19:24

Message:
Logged In: YES 
user_id=112690

As suggested by Tim I'll upload here the patch and the test
for this bug.
The patch clears nb_true_divide entry and deletes the
complex_int_div function.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470



From noreply@sourceforge.net  Tue May 21 19:18:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 11:18:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-533291 ] __reduce__ does not work as documented
Message-ID: <E17AEDN-0003z0-00@usw-sf-web4.sourceforge.net>

Bugs item #533291, was opened at 2002-03-21 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Raymond Hettinger (rhettinger)
Summary: __reduce__ does not work as documented

Initial Comment:
The documentation for __reduce__ says that the second
element of the returned tuple can either be a tuple
of arguments or None.  The copy module does not handle
the None case:

  class C(object):
    def __reduce__(self):
        return (C, None)

  import copy
  copy.copy(C())



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-21 14:18

Message:
Logged In: YES 
user_id=6380

Wouldn't it be better if the warning came on the pickling
side instead of on the unpickling side?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 13:23

Message:
Logged In: YES 
user_id=80475

Committed libpickle.tex 1.36 and pickle.py 1.62.
Closing patch.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-21 11:42

Message:
Logged In: YES 
user_id=3066

Issues with the doc portion the patch:

- "/deprecated" should be spelled "\deprecated"

- Deprecations are whole paragraphs; don't include them
  inside parenthetical expressions.  Make them separate
  paragraphs which preceed or succeed the relevant
  material in the documentation.

Once appropriate corrections are made, I'm fine with the patch.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-15 23:14

Message:
Logged In: YES 
user_id=80475

See attached documentation and code patch for deprecating 
the None version.  If approved, re-assign to Raymond for 
commit.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:36

Message:
Logged In: YES 
user_id=6380

So be it.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 12:09

Message:
Logged In: YES 
user_id=35752

I would prefer that the None version be deprecated.  The
documentation for __reduce__ is confusing enough as it is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 11:59

Message:
Logged In: YES 
user_id=6380

I'm not sure it's that simple. While pickling a C instance
indeed succeed, unpickling it raises a strange exception:

>>> pickle.loads(pickle.dumps(C()))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/guido/trunk/Lib/pickle.py", line 982, in loads
    return Unpickler(file).load()
  File "/home/guido/trunk/Lib/pickle.py", line 593, in load
    dispatch[key](self)
  File "/home/guido/trunk/Lib/pickle.py", line 842, in
load_reduce
    value = callable.__basicnew__()
AttributeError: type object 'C' has no attribute
'__basicnew__'
>>>

It appears that an argument tuple of None signals some
special Jim-Fulton-only behavior. __basicnew__ is a feature
of ExtensionClasses (similar to __new__ in Python 2.2), and
while ExtensionClasses work in 2.2, they're being
deprecated: Zope 2.x will continue to use Python 2.1.x, and
Zope 3 will require Python 2.2 or higher.

The copy module has never worked for ExtensionClass
instances (unless maybe the class defines a __copy__
method).

Maybe the right thing to do is to document 'None' as a
special case that one shouldn't use, and deprecate
__basicnew__?

(Hm, OTOH why don't I just approve your fix so we can stop
thinking about this. :-)

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 10:10

Message:
Logged In: YES 
user_id=35752

Added trivial patch to fix copy.py module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470



From noreply@sourceforge.net  Tue May 21 19:21:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 11:21:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E17AEGF-0002fO-00@usw-sf-web2.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 08:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Raymond Hettinger (rhettinger)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 13:21

Message:
Logged In: YES 
user_id=80475

Committed as:
  libfuncs.tex 1.106
  libstdtypes.tex 1.94
  ref5.tex 1.62

Closing patch.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-21 12:54

Message:
Logged In: YES 
user_id=3066

Thanks!  Go ahead and check it in.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 12:46

Message:
Logged In: YES 
user_id=80475

Separated the \deprecated sections.  Revised patch attached.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-21 11:10

Message:
Logged In: YES 
user_id=3066

The \deprecated markup should always be a separate paragraph
(or list item).  Please revise the doc patch and re-submit
for review.  (But thanks for working on this; the content is
good!)

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-13 01:29

Message:
Logged In: YES 
user_id=80475

Fred, here's a doc patch.
Okay to commit and close this bug?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 07:37

Message:
Logged In: YES 
user_id=6380

Note: complex % is also being deprecated.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:42

Message:
Logged In: YES 
user_id=6380

Fred, can you fix the docs?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:36

Message:
Logged In: YES 
user_id=6380

OK, I'll add the deprecation warning.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-14 20:23

Message:
Logged In: YES 
user_id=31435

Heh.  divmod(c1, c2)[0] for complexes returns
  floor((c1/c2).real)
according to the Reference Manual (5.6 Binary arithmetic 
operations), and it looks like the code implements that 
just so.  The Library manual's "Builtin Functions" section 
only mentions ints, longs and floats, while the same 
manual's "2.2.4 Numeric Types" claims, in a footnote, 
that "Builtin Functions" told the full truth about divmod.

The primary lesson I take from this is that a .chm file is 
a truly wonderful way to search the docs <wink>.

I don't think divmod is useful for complexes, and would be 
happy to see it go away.  But I guess that means taking the 
full-blown deprecation path.

I note that the original complexobject.c didn't implement 
divmod.  The current divmod appears to derive from a patch 
contributed by Tim Hochberg, in rev 2.10 in 1996.  You 
(Guido) added a question mark to the checkin comment, so I 
figure it never made much sense to you either.

I agree floor divsion and divmod(...)[0] should do the same 
thing, whatever that is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 19:44

Message:
Logged In: YES 
user_id=6380

Hm. I believe that if divmod() returns something, // should
return the same thing (well, divmod()[0]). But what on earth
does divmod() do on two complex numbers??? Does it make
sense to have divmod() on complex at all? Assigned to Tim
for a ruling.

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 18:24

Message:
Logged In: YES 
user_id=112690

As suggested by Tim I'll upload here the patch and the test
for this bug.
The patch clears nb_true_divide entry and deletes the
complex_int_div function.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470



From noreply@sourceforge.net  Tue May 21 19:31:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 11:31:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-555035 ] rfc822.Message.getaddrlist broken
Message-ID: <E17AEQ7-0003Qf-00@usw-sf-web3.sourceforge.net>

Bugs item #555035, was opened at 2002-05-12 02:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555035&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry Warsaw (bwarsaw)
Summary: rfc822.Message.getaddrlist broken

Initial Comment:
rfc822.Message.getaddrlist() uses an AddressList 
instance as a helper.  AddressList objects parse 
their inputs during __init__.  Calling 
a.getaddrlist() thus causes the parsing to start 
over, but with the position set past the end of the 
address string.  Instead of calling 
AddressList.getaddrlist() 
rfc822.Message.getaddrlist() should simply access the 
addresslist attribute, e.g., at the end of that 
method it should read:

    alladdrs = ''.join(raw)
    a = AddressList(alladdrs)
    return a.addresslist

Here's a simple example that demonstrates the problem:

    >>> import rfc822
    >>> a = rfc822.AddressList ("skip@pobox.com")
    >>> a.getaddrlist()
    []
    >>> a.addresslist
    [('', 'skip@pobox.com')]

Bugfix candidate?

Skip


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-05-21 14:31

Message:
Logged In: YES 
user_id=12800

Yup, I recently ran into something similar.  Your analysis
is spot on of course, as is your proposed fix.  I will
commit changes to rfc822.py and to test_rfc822.py.  

Yes, this is a bug fix candidate.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=555035&group_id=5470



From noreply@sourceforge.net  Tue May 21 21:34:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 13:34:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-210648 ] performance-problem decoding quoted-printable (PR#340)
Message-ID: <E17AGKl-00045r-00@usw-sf-web2.sourceforge.net>

Bugs item #210648, was opened at 2000-07-31 14:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210648&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Invalid
Priority: 4
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: performance-problem decoding quoted-printable (PR#340)

Initial Comment:
Jitterbug-Id: 340
Submitted-By: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <ragnark@vestdata.no>
Date: Fri, 26 May 2000 16:51:51 +0200
Version: None
OS: None

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi

Problem on python 1.5.1 on linux 2.2.14aa6.

Decoding quoted-printable files using mimetools.decode is really slow.
The really strange thing is, that it appers to work a lot faster on
smaller files!

I put together a little test-program that reads blocks from a file, and
decodes them individually. (The output will not be 100% correct. The
point was just to test the performance). 

Results show the time it took to decode a 300k file with the diferent
block-sizes:
1k:	6.28 s
3k:	6.59 s
10k:	8.57 s
30k:	30.45 s
100k:	127.82 s
300k:	221.67 s

I looked in quopri.decode for clues about the problem, but could not
find any. Is there something _very_ wrong with my reasoning, or is
something wrong here?



-- 
Ragnar Kjørstad

--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="test.py"

#!/usr/bin/python
from mimetools import decode
from StringIO import StringIO
from sys import stdout, argv
from string import atoi
bsize=atoi(argv[1])
output=StringIO()
f=open("mail-test")
s=f.read(bsize)
while s:
	input=StringIO(s)
	decode(input, output, 'quoted-printable')
	s=f.read(bsize)
	stdout.write('.')
	stdout.flush()
stdout.write('done\n')

--7JfCtLOvnd9MIVvH--



====================================================================
Audit trail:
Tue Jul 11 08:25:57 2000	guido	moved from incoming to open

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-21 13:34

Message:
Logged In: NO 

I've been able to reproduce this using ActivePython 2.1 
(build 210) on Windows 2000.

The (apparent) solution is to replace the recursive "new = 
new + c" with a simple "output.write(c)". Seems kind of silly 
to write a single character at a time, but it took my mail 
program from infinite loop (running through mod_python) to 
decoding a 5MB attachment in seconds.

Thoughts?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-23 10:10

Message:
Logged In: NO 

Ive reproduced this problem.  The file that gives the 
library fits is a PDF file that reports as quoted-printable.
The file is an actual PDF sent with Microsoft Outlook.
Every line in the quoted-printable ends in an =.

It looks like the decode function will keep appending to
a single line if it finds an = at the end of the line.  This
is the flag that tells the quopri.decode that the line is
a partial line.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-21 18:35

Message:
I marked this Invalid and Closed.  There *may* have been a buffering problem in 1.5.2 that got fixed, or it may simply be that the original report used an unrealistic input file (which is what I suspect -- gory details below), or both.  But note that the true complaint ("decode is really slow") probably remains valid.

There's *something* still going on here in 2.0b1, at least under Win98SE.  Here's the output from a more self-contained version of the program:

C:\Python20>python mtest.py
      1024        4.6
      2048        6.1
     10240        7.9
     30720        8.8
    102400        8.9
    307200        9.4
      1024        4.5
      2048        5.8
     10240        8.3
     30720        8.9
    102400        9.0
    307200        9.4

C:\Python20>

That's with everything in cache, and there's a very clear & reproducible factor-of-2 advantage to using the small blocksize.  Here's the program:

BIGFILE = "DLLs/tk83.dll"

def timer(fname, blockseq):
    from mimetools import decode
    from StringIO import StringIO
    from time import clock
    for mult in blockseq:
        start = clock()
        bsize = mult * 1024
        output = StringIO()
        f = open(fname, "rb")
        s = f.read(bsize)
        while s:
            input = StringIO(s)
            decode(input, output, 'quoted-printable')
            s = f.read(bsize)
        f.close()
        del output, f, s, input
        finish = clock()
        print "%10d %10.1f" % (bsize, finish - start)

if __name__ == "__main__":
    timer(BIGFILE, (1, 2, 10, 30, 100, 300) * 2)

Of course, I'm reading in a binary file there, so the test makes no real sense!  And I *suspect* the original bug report also used a nonsense file.  Why that's important will become clear soon.

If I interrupt the program at random, it's usually on line 72 of quopri.py:

  File "C:\PYTHON20\lib\quopri.py", line 72, in decode
    new = new + c; i = i+1

That hints at a problem with the quadratic-time nature of repeated appends.  Conventional wisdom is that's just theoretical, but it isn't, and the crossover point is highly platform-dependent.

If I replace the call to decode with:

            while 1:
                line = input.readline()
                if not line:
                    break
                new = ""
                for ch in line:
                    pass
                output.write(line)

then there's no apparent dependence on block size.  So this is not a problem with buffering, it's specific to decode.

But if I replace the "pass" with

new = new + ch

then I get back a very strong dependence on block size.  And that loop is what decode does, except for the useful parts <wink>.

So that explains *my* glitch:  the smaller the blocksize, the more "lines" get artificially created, the smaller the longest lines become, and the less the ch-at-a-time append can hurt.  But this is all an artifact of me using a binary file for input!  That is, it's an artifact of using a test file with nearly arbitrarily long "lines".

If I create a giant 4Mb text file via catenating all the *.html files in the Windows Python doc/lib directory, there is no dependence on blocksize in the test program, other than that it gets a little *faster* the larger the block size.  And that's what I'd expect (repeated catenation is linear-time on all platforms I've heard of, so long as the lines are reasonably short).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-19 11:11

Message:
Can't reproduce it either. Note he's using Python 1.5.1. Maybe it was a buffering problem in StringIO there - quopri.py is using readline(). Barry, if you don't have another idea, just close it as Invalid.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2000-09-19 09:52

Message:
I can't reproduce the problem. On  sparc-sun-solaris2.6, Python 1.5.2 needs the same time for a 330k file, regardless of the block size.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210648&group_id=5470



From noreply@sourceforge.net  Wed May 22 00:02:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 16:02:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-558914 ] Build md5.c fails on Cray T3E
Message-ID: <E17AIeJ-0005mq-00@usw-sf-web2.sourceforge.net>

Bugs item #558914, was opened at 2002-05-22 11:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558914&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hadfield (hadfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build md5.c fails on Cray T3E

Initial Comment:
Building Python 2.2.1 on Cray T3E, compilation of md5.c
and md5module.c fails because UINT4 is undefined. The 
T3E does have an unsigned, 4-byte integer data type
(namely short) but the following code in Modules/md5.h
fails to find it:

/* UINT4 defines a four byte word */
#if SIZEOF_LONG == 4
typedef unsigned long int UINT4;
#else
#if INT_MAX == 2147483647
typedef unsigned int UINT4;
#endif
/* Too bad if neither is; pyport.h would need to be
fixed. */
#endif

So I changed it to:

/* UINT4 defines a four byte word */
#if SIZEOF_LONG == 4
typedef unsigned long int UINT4;
#elif SIZEOF_SHORT == 4
typedef unsigned short int UINT4;
#elif INT_MAX == 2147483647
typedef unsigned int UINT4;
#endif
/* Too bad if neither is; pyport.h would need to be
fixed. */

Also, Modules/md5.h defines a UINT2. This is a worry
because T3E's don't have a 2-byte integer data type. It
turns out that this symbol is never used.

With modified Modules/md5.h (attached), the md5 module
compiles OK and passes tests.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558914&group_id=5470



From noreply@sourceforge.net  Wed May 22 03:28:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 May 2002 19:28:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-551828 ] PDF won't print
Message-ID: <E17ALrR-0007wI-00@usw-sf-web2.sourceforge.net>

Bugs item #551828, was opened at 2002-05-03 08:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551828&group_id=5470

Category: Documentation
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Shaun Devlin (ssdevlin)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PDF won't print

Initial Comment:
On Windows 98SE with Acrobat reader 5.0.5
several pdf documents (inst.pdf, whatnew.pdf, ref.pdf,
etc) will not print although they display fine.
This has been observed on two computers and two printers
(Laser Jet IIIP, Brother HL-1650) neither with hardware
postscript emulation.
Sometimes the first page prints.
These systems can print other pdf documents

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-21 22:28

Message:
Logged In: YES 
user_id=3066

This is an Acrobat bug.  See the comments near the end of
http://www.python.org/doc/current/download.html.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-05-05 16:51

Message:
Logged In: YES 
user_id=45365

The same is true on Mac OS X, Acrobat Reader 5.0. Observed on a LaserJet 4500. It is also true for other documents formatted with the Python TeX macro stuff, such as the recent unicode document. Some documents print a few pages, some print nothing at all.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551828&group_id=5470



From noreply@sourceforge.net  Wed May 22 12:09:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 May 2002 04:09:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-559117 ] HTTPSConnection memory leakage
Message-ID: <E17AU0A-00069B-00@usw-sf-web4.sourceforge.net>

Bugs item #559117, was opened at 2002-05-22 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559117&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Paolo Andreetto (pandreetto)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPSConnection memory leakage

Initial Comment:
I've tried this test script:

import time,httplib,gc

gc.set_debug(gc.DEBUG_STATS)

while 1:
	conn=httplib.HTTPSConnection('<myhostip>')
	conn.connect()
	conn.request('GET', '/index.html')
	res=conn.getresponse()
	conn.close()
	time.sleep(1)
	print gc.collect()

and I've seen that a memory leakage occurs. The process
requires 4Kbytes every 10 seconds. The output of
garbage collector shows that at the end of each cycle a
new object is contained into last generation.
I've tried also to remove from the script both the
conn.request and the conn.getresponse but nothing has
changed; perhaps the problem is in the connect() method.
All tests run on linux (debian distribution, sid
version for i386) with kernel 2.4.18 and python 2.1.3.
The web server is apache with mod-ssl on redhat 7.2.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559117&group_id=5470



From noreply@sourceforge.net  Wed May 22 14:57:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 May 2002 06:57:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E17AWcQ-0008EV-00@usw-sf-web1.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 19:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Programs using Tkinter sometimes can't shut down (Windows)

Initial Comment:
The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS.  In my case, I was running IDLE via

python ../tool/idle/idle.pyw

from a DOS box in my PCbuild directory.  Win98SE.  *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging.  As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap.

-----Original Message-----
From: Joseph Stubenrauch <nothingisgoingtochangemyworld@yahoo.com>
Sent: Friday, October 06, 2000 9:23 PM
To: tutor@python.org
Subject: Re: [Tutor] Python 1.6 BUG


Strange, I have been experiencing the same bug myself.
Here's the low down for me:

Python 1.6 with win95
I am running a little Tkinter program
The command line I use is simply: "python foo.py"
About 25-35% of the time, when I close the Tkinter
window, DOS seems to "freeze" and never returns to the
c:\ command prompt.  I have to ctrl-alt-delete
repeatedly and shut down "winoldapp" to get rid of the
window and then shell back into DOS and keep working.
It's a bit of a pain, since I have the habit of
testing EVERYTHING in tiny little stages, so I change
one little thing, test it ... freeze ... ARGH!  Change
one more tiny thing, test it ... freeze ... ARGH! 
However, sometimes it seems to behave and doesn't
bother me for an entire several hour session of python
work.

That's my report on the problem.

Cheers,

Joe


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-22 06:57

Message:
Logged In: NO 

I am new to Python and encountered this bug on my very first 
Tkinter application.  It persists in Python 2.2.1 under 
Windows Me. Needless to say, it makes a bad first 
impression.  Basically, this thread says that Tkinter has been 
broken for a year and a half on a popular platform at a time 
when Python is trying to expand its user base.  Hopefully, this 
bug will be corrected soon.

If Tcl/Tk 8.4 is not released shortly you might try repackaging 
Tkinter for Win32 with an earlier version of Tcl/Tk, such as 
8.0, that doesn't encounter this problem.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 19:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 18:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 17:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 16:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 15:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 15:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 14:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 15:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 01:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 10:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 13:06

Message:
Logged In: YES 
user_id=31435

No sign of progress on this presumed Tk/Tcl Windows bug in 
over 3 months, so closing it for lack of hope.

----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2001-02-05 21:13

Message:
This was a symptom I saw while tracking down the essence of the problem reported in #131207.  Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-12-12 18:00

Message:
Just reproduced w/ current CVS, but didn't hang until the 8th try.

http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 12:58

Message:
Tim, can you still reproduce this with the current CVS version?

There's been one critical patch to _tkinter since the 2.0 release.

An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?).


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-15 09:47

Message:
Same as I've reported earlier; it hangs in the call to
Tcl_Finalize (which is called by the DLL finalization
code).  It's less likely to hang if I call Tcl_Finalize
from the _tkinter DLL (from user code).

Note that the problem isn't really Python-related -- I
have stand-alone samples (based on wish) that hangs in
the same way.

More later.

</F>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 07:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 10:25

Message:
The recent fix to _tkinter (Tcl_GetStringResult(interp) instead of interp->result) didn't fix this either.

As Tim has remarked in private but not yet recorded here, a workaround is to use pythonw instead of python, so I'm lowering thepriority again.

Also note that the hanging process that Tim writes about apparently prevents Win98 from shutting down properly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-10-07 00:37

Message:
More info (none good, but some worse so boosted priority):

+ Happens under release and debug builds.

+ Have not been able to provoke when starting in the debugger.

+ Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up.  There's still a Python (or Python_d) process hanging around that Ctrl+Alt+Del doesn't show.

+ This process makes it impossible to delete the associated Python .dll, and in particular makes it impossible to rebuild Python successfully without a reboot.

+ These processes cannot be killed!  Wintop and Process Viewer both fail to get the job done.  PrcView (a freeware process viewer) itself locks up if I try to kill them using it.  Process Viewer freezes for several seconds before giving up.

+ Attempting to attach to the process with the MSVC debugger (in order to find out what the heck it's doing) finds the process OK, but then yields the cryptic and undocumented error msg "Cannot execute program".

+ The processes are not accumulating cycles.

+ Smells like deadlock.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470



From noreply@sourceforge.net  Wed May 22 17:56:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 May 2002 09:56:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-557436 ] TclError is a str should be an Exception
Message-ID: <E17AZPz-00009n-00@usw-sf-web2.sourceforge.net>

Bugs item #557436, was opened at 2002-05-17 22:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557436&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: TclError is a str should be an Exception

Initial Comment:
Since string exceptions are deprecated, it seems that
TclError (in _tkinter.c) should be changed to derive
from Exception.

It isn't apparent to me how to accomplish this.  If
someone can provide a quick high-level description, I
can make a patch.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-22 18:56

Message:
Logged In: YES 
user_id=21627

The official API is PyErr_NewException, where NULL as the
base class indicates to inherit from Exception.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 10:45

Message:
Logged In: YES 
user_id=80475

Try makeclass() in Python/exceptions.c -- the file also 
shows how all the built-in exceptions get created.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557436&group_id=5470



From noreply@sourceforge.net  Thu May 23 00:20:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 May 2002 16:20:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-556025 ] list(xrange(1e9))  -->  seg fault
Message-ID: <E17AfOk-0003rq-00@usw-sf-web2.sourceforge.net>

Bugs item #556025, was opened at 2002-05-14 12:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Neal Norwitz (nnorwitz)
Summary: list(xrange(1e9))  -->  seg fault

Initial Comment:
>From c.lang.py:

'''
 Python 2.2.1 (#2, Apr 21 2002, 22:22:55) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> list(xrange(1e9))
Segmentation fault
'''

I've reproduced the same fault on Windows ME using 
Py2.2.0 and Py2.3a.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-22 19:20

Message:
Logged In: YES 
user_id=33168

Checked in as:
  listobject.c 2.106
  test_b1.py 1.46

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-21 08:59

Message:
Logged In: YES 
user_id=80475

Good plan!  Thx for squashing this bug. 

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-21 08:52

Message:
Logged In: YES 
user_id=33168

How about using sys.maxint / 4?  Does that make more sense
than 1e9?  This assumption is a little better, that the data
and address sizes are the same.  I can add a comment to this
effect.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 23:37

Message:
Logged In: YES 
user_id=80475

When you load the fix, please commit the regression test 
patch also.  Thx,  Raymond

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 22:51

Message:
Logged In: YES 
user_id=31435

Yup, lookin' better.  Python does assume 8-bit bytes in 
several places, and also 2's-complement integers.  Since 
size_t is guaranteed (by C) to be an unsigned type, the 
largest value of type size_t is more easily expressed as

(~(size_t)0)

The C part of the patch looks fine then.  The test is a 
little dubious:  who says the machine can't create a 
billion-integer list?  The idea that 1e9 necessarily 
overflows in this context is a 32-bit address-space 
assumption.  But I'm willing to delay fixing that until a 
machine with a usable larger address space appears <wink>.

So marked Accepted and assigned to you for checkin.  Thanks!

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-20 11:43

Message:
Logged In: YES 
user_id=33168

Ok, there were other problems, too:
  * Need to divide by the size of the type, 
    not >> 4 which was completely broken.
  * There was a missing PyErr_NoMemory().

I uploaded a new patch.

I'm not sure the size_t fix is correct.
I hope we can at least assume 8-bit machines: :-)

if (_new_size <= ((1 << (sizeof(size_t)*8 - 1)) / sizeof(type)))



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 00:48

Message:
Logged In: YES 
user_id=31435

The code patch has some problems:  you can't assume any 
relation between a size_t and an unsigned long; C simply 
doesn't define how big size_t is, and relative sizes do 
vary on 64-bit platforms.  However that gets fixed, if you 
decide it's "too big", var should be set to NULL (not 0 -- 
this is a "Guido thing" <wink>), and no exception should be 
set.  It's the caller's responsibility to check var for 
NULL after the macro is invoked, and set an appropriate 
exception.  listobject.c sometimes doesn't check the result 
for NULL, but that should only be when it knows it's 
*shrinking* a memory area, so that realloc can't fail.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-17 20:12

Message:
Logged In: YES 
user_id=80475

Added a patch to add this bug to the testbank.

Shallow code review:  Patch compiles okay (applied to 
Py2.3a0). Fixes the original problem.  Passes the smell 
test.  Macro style good (only the "var" operand is used 
more than once; no side-effects except setting "var" to 
zero upon a resize error).  Passes the standard regression 
tests.  Passes regression testing versus my personal (real 
code) testbank.

Will give it a deeper look this week-end.

One other thought: should the ValueError be replaced with a 
MemoryError to make the message consistent with PyList_New?



----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 17:03

Message:
Logged In: YES 
user_id=33168

Ok, this time I have a patch.  The patch only fixes listobject.

I looked over the other uses of PyMem_R{ESIZE,ALLOC}() and
they don't appear to be nearly as problematic as list.  For
example, if the grammar has 1e9 nodes, there are going to be
other problems well before then (ie, memory will probably be
gone).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:25

Message:
Logged In: YES 
user_id=33168

Oops, sorry about that last comment.  That was something I
was playing with.  The CVS version is fine for [x]range(float).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-17 16:22

Message:
Logged In: YES 
user_id=33168

Note, this problem is even more generic in CVS version:

>>> range(1.1)
Segmentation fault (core dumped)
>>> xrange(1.1)
Segmentation fault (core dumped)

[x]xrange(float) work fine in 2.2.1.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 20:44

Message:
Logged In: YES 
user_id=80475

Would there be some merit to converting PyMem_RESIZE to a 
function with an overflow check?  

I would guess that the time spent on a realloc dwarfs the 
overhead of a short wrapper function.

OTOH, I'll bet this core dump only occurs in toy examples 
and never in real code.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-14 18:15

Message:
Logged In: YES 
user_id=31435

Heh.  This is an instance of a general flaw:  the 
PyMem_RESIZE macro doesn't check for int overflow in its

    (n) * sizeof(type)

subexpression. The basic deal is that 1000000000 fits in an 
int, but 4 times that (silently) overflows.  In more 
detail, for this specific test case, listobject.c'.s 
roundupsize rounds 1e9 up to 0x40000000, which silently 
underflows to 0!() when PyMem_RESIZE multiplies it by 4.

Hard to know how to fix this in general; PyMem_RESIZE 
callers don't generally worry about overflow now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=556025&group_id=5470



From noreply@sourceforge.net  Thu May 23 01:32:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 May 2002 17:32:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-559429 ] __gxx_personality_v0 not found by ld
Message-ID: <E17AgWo-0005MV-00@usw-sf-web3.sourceforge.net>

Bugs item #559429, was opened at 2002-05-22 17:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559429&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: george r. goffe (grgoffe)
Assigned to: Nobody/Anonymous (nobody)
Summary: __gxx_personality_v0 not found by ld

Initial Comment:

Howdy,

I'm building Python-2.2.1 on a solaris 2.8 system and
am having trouble. The loader can not find the above
named external reference.

I'm enclosing the build log that shows (probably) more
than you ever wanted to know but it DOES show the
problem.

Any/all help/hints/tips would be appreciated.

Regards,

George...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559429&group_id=5470



From noreply@sourceforge.net  Thu May 23 11:24:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 May 2002 03:24:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-542003 ] Compile fails on posixmodule.c
Message-ID: <E17Apm2-0002cd-00@usw-sf-web3.sourceforge.net>

Bugs item #542003, was opened at 2002-04-10 14:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542003&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Manic Hawk (manichawk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compile fails on posixmodule.c

Initial Comment:
OS: Slackware Linux 7.0
Kernel: 2.4.18
Glibc: 2.1.2
Python: 2.2.1 release (not candidate)
Configure args: ./configure

Compile fails on posixmodule.c (attempted twice, with 
a make distclean between):

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -
I./Include -DHAVE_CONFIG_H   -
c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-05-23 10:24

Message:
Logged In: YES 
user_id=6656

Indeedy.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-10 18:09

Message:
Logged In: YES 
user_id=21627

This appears to be a duplicate of 535545.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542003&group_id=5470



From noreply@sourceforge.net  Thu May 23 20:46:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 May 2002 12:46:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-506647 ] random.cunifvariate() incorrect?
Message-ID: <E17AyXx-0007wi-00@usw-sf-web4.sourceforge.net>

Bugs item #506647, was opened at 2002-01-21 16:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506647&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Maciej Kalisiak (abcdefghijklmno)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.cunifvariate() incorrect?

Initial Comment:
random.cunifvariate() currently is defined as:
  return (mean + arc * (self.random() - 0.5)) % _pi

First of all, this returns values in the range [0, pi)
due to the modulus, which really makes it a
semi-circular distribution, not circular (but I'm not a
mathie, so perhaps I'm wrong).

I think the normalizing step ("% _pi", or whatever this
gets changed to) should probably be mentioned in the
documentation for this function; it caught me by
surprise, and I expect it will catch some others too.  

With this defintion, the function returns a random
value in the range [mean-arc/2, mean+arc/2).  The docs
say that arc, like mean, can only be in the range
[0,pi].  This would imply that one cannot get values in
the other half of the circle, i.e. [pi, 2*pi).  Since
there doesn't seem to be anything stopping the caller
from using an arc in [0,2*pi], perhaps the
documentation should be updated?


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-23 14:46

Message:
Logged In: YES 
user_id=80475

Added normalization comment to docs put in a 
deprecation warning.  Committed as random.py 1.33 and 
librandom.tex 1.29.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-20 22:27

Message:
Logged In: YES 
user_id=80475

So be it.  

If there are no objections received before Thursday May 
24th, I'll deprecate it.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-05-20 22:11

Message:
Logged In: YES 
user_id=31435

I recommend to deprecate this function instead of "fixing" 
it.  If we deprecate it in 2.3, we can lose it entirely for 
2.4.  The function appears useless to me with or without 
the suggested fixes, and anyone who *did* want 
something "like this" would just call random.uniform() 
passing appropriate bounds anyway.  Indeed, Raymond's patch 
amounts to making cunifvariate a synonym for calling 
random.uniform(mean-arc/2, mean+arc/2).  We don't need a 
separate function for something so trivial.

BTW, I've never seen the word "cunifvariate" outside of 
Python's random module.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-15 06:00

Message:
Logged In: YES 
user_id=21627

I'm not qualified to comment on the correctness of this
change, so unassigning it. Maybe Tim knows what a
cunifvariate is?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-14 16:53

Message:
Logged In: YES 
user_id=80475

Martin, please approve the patch and I'll load it for Py2.3.

The docs don't match the function and the actual behavior 
is weird.  Thinking in degrees, calling with a mean of 175 
and an arc of 20 returns {x | 0<x<5 or 165<x<180} with an 
expected mean of 130 instead of the specified mean of 175.

Google reports no non-Python examples of cunifvariate so 
there is no standard to match against.

The patch removes the Pi normalization in the 
implementation and removes the superfluous domain 
restriction in the docs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506647&group_id=5470



From noreply@sourceforge.net  Thu May 23 21:55:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 May 2002 13:55:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
Message-ID: <E17AzcG-0006NQ-00@usw-sf-web2.sourceforge.net>

Bugs item #210682, was opened at 2000-07-31 23:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Later
Priority: 1
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb can only step when at botframe (PR#4)

Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

----------------------------------------------------------------------

>Comment By: Christian Tismer (tismer)
Date: 2002-05-23 22:55

Message:
Logged In: YES 
user_id=105700

There appears to be a simple solution.
I'm not used to pdb very much, so I cannot fur sure
say that my patch doesn't affect any extension of it,
but it seems to work just fine.

Idea: Allow botframe not to be a frame at all, but also None.
This makes it possible to use f_back in line 67:
            self.botframe = frame.f_back ##!!CT
In stop_here, we just omit the first two lines:
    def stop_here(self, frame):
        ##!!CT if self.stopframe is None:
        ##!!CT     return 1
        if frame is self.stopframe:
            return 1
        while frame is not None and frame is not self.stopframe:
            if frame is self.botframe:
                return 1
            frame = frame.f_back
        return 0

By this trick, botframe is llowed to be one level "on top"
of the
topmost frame, and we see the topmost frame behave as nicely
as every other.

-- chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 23:55

Message:
Logged In: YES 
user_id=6380

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:30

Message:
Logged In: YES 
user_id=31392

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 16:19

Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 16:18

Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470



From noreply@sourceforge.net  Thu May 23 22:59:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 May 2002 14:59:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-534158 ] Running MacPython as non-priv user may fail
Message-ID: <E17B0cc-0006xX-00@usw-sf-web2.sourceforge.net>

Bugs item #534158, was opened at 2002-03-24 00:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534158&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Running MacPython as non-priv user may fail

Initial Comment:
Running Python (especially the IDE, but possibly also the interpreter from a non-standard place)on OSX as a non-privileged user if you've previously installed it system-wide (as a privileged user) may not work the first time. In some cases it will start to work automatically, in other cases you have to throw away the (per-user) preferences file.

At the very least we need to warn for this in the README.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-05-23 23:59

Message:
Logged In: YES 
user_id=45365

A note was added to the read me file (some time ago already). Really fixing this is difficult, and will probably not happen in MacPythons lifetime.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-03-25 15:53

Message:
Logged In: YES 
user_id=45365

Added a note to the readme for 2.2.1.

Lowering the priority, it may be a while before I get around to all the OSX multiuser intricacies.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534158&group_id=5470



From noreply@sourceforge.net  Thu May 23 23:05:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 May 2002 15:05:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-493826 ] Finder Tool Move not working on MOSX
Message-ID: <E17B0i3-00071R-00@usw-sf-web2.sourceforge.net>

Bugs item #493826, was opened at 2001-12-16 08:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493826&group_id=5470

Category: Macintosh
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Benjamin Schollnick (bscholln)
Assigned to: Jack Jansen (jackjansen)
Summary: Finder Tool Move not working on MOSX

Initial Comment:
Under Mac OS X v10.1.1, Mac Python does not seem to
handle a findertool move command.

old:  Macintosh HD:Desktop Folder:downloads:
new: Macintosh HD:Desktop Folder:downloads:Achikatactics
filename: ACHIKA_TACTICS_2_00.JPG
old + file: Macintosh HD:Desktop
Folder:downloads:ACHIKA_TACTICS_2_00.JPG
Traceback (most recent call last):
  File "OS v9.1:Desktop Folder:python
work:re-dup-file.py", line 104, in ?
  File "OS v9.1:Desktop Folder:python
work:re-dup-file.py", line 53, in move_file
  File "OS v9.1:Applications (Mac OS 9):Python
2.1.1:Mac:Lib:findertools.py", line 74, in move
  File "OS v9.1:Applications (Mac OS 9):Python
2.1.1:Mac:Lib:lib-scriptpackages:Finder:Standard_Suite.py",
line 293, in move
aetools.Error: (0, 'component result = no error', None)

The file *does* get moved, but the above trace is reported.

I'll append the actual code, once I boot back to OS 9.

The same code *DOES* work under OS 9... (So it is
restricted to Mac OS X 10.1.1).  

I do not *REMEMBER* seeing the problem in earlier
versions of Mac OS X, but that is suspect.  (I can't
say for certain that it doesn't appear).

    - Benjamin

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-05-24 00:05

Message:
Logged In: YES 
user_id=45365

Fixed a while ago (the fix is already in 2.2.1): even though the Finder is incorrect IMNSHO the suite modules have been regenerated to treat a 0 "errn" return value the same as a missing "errn" (i.e. no error).

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-12-20 22:46

Message:
Logged In: YES 
user_id=45365

My feeling is that the problem is with the finder, not with Python. The 10.1.1 finder apparently returns an 'errn'
parameter (keyErrorNumber) with value 0. My interpretation (and every other scriptable app in the world) does not return any 'errn' parameter in the no-error case.

I suggest you file this as a bug with Apple. If they won't fix it I'll do so (reluctantly;-). In the mean time you can work around the problem by replacing all the 
    if has_key(_arguments, 'errn'):
with
    if has_key(_arguments, 'errn') and _arguments['errn'] != 0:


----------------------------------------------------------------------

Comment By: Benjamin Schollnick (bscholln)
Date: 2001-12-20 14:06

Message:
Logged In: YES 
user_id=3811

This is the code that is producing the error...

Please keep in mind, it works fine in OS 9.x.x or earlier 
under MacPython.  Only under MOSX does it appear to fail.
(Even then the file does get moved, but an exception is 
raised).

def		move_file ( old_path, new_path, filename ):
#			try:
				print "---------------------
----------------"
				print "old: ",old_path
				print "new:",new_path
				print "filename:",filename
				print "old + file:", 
old_path + filename

				if os.path.exists (new_path 
+ os.sep + filename):
					Ask = 
EasyDialogs.AskYesNoCancel("Duplicate File Detected (%s), 
Overwrite?" % filename, default = 1, yes=None, no=None, 
cancel=None, id=262)
					if Ask == 1:
						if mac_mode:
							# 
Overwrite, by removing the old file
							#
						
	os.remove(new_path + os.sep + filename)
							
					elif Ask == 0:
							#
							#
	Do not overwrite, end routine, by returning
							#
						return 0
						
					elif Ask == -1:
							#
							#
	Abort program, return error code
							#
						return -1
				
				if mac_mode:
					findertools.move 
(old_path + filename, new_path)
#			except:
#				pass
			
#			return None
		


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493826&group_id=5470



From noreply@sourceforge.net  Thu May 23 23:07:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 May 2002 15:07:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-494572 ] plugin project generation has problems
Message-ID: <E17B0k2-00072z-00@usw-sf-web2.sourceforge.net>

Bugs item #494572, was opened at 2001-12-18 14:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494572&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: plugin project generation has problems

Initial Comment:
The generation of CW7 projects for plugins (and
distutils too, probably) still has some problems that
cause CW to say the project was created by an older
version of  CodeWarrior. The project does work, but
this needs to be fixed before 2.2 final.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-05-24 00:07

Message:
Logged In: YES 
user_id=45365

This problem seems to have disappeared.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-12-22 00:31

Message:
Logged In: YES 
user_id=45365

Ah, what! Lowering this to 5, as it's really only a problem for people who have CodeWarrior, who'll have to press "OK" to the "update from older project version?" question when they're building a distutils package.

(of course, the real reason for lowering the priority is that I want to get 2.2 out the door, AND NOTHING WILL STOP ME, HAHAHAHAHA!!!)

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2001-12-21 17:58

Message:
Logged In: YES 
user_id=12800

Back to priority 7 so Jack doesn't forget, but it still will
not hold up the source or windows release.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2001-12-21 17:55

Message:
Logged In: YES 
user_id=12800

Sorry Jack, bumping this down to priority 6 and deferring
for post-2.2 final (although you have permission to make any
Mac-only changes that might be necessary for the Mac 2.2
final release).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-19 21:34

Message:
Logged In: YES 
user_id=21627

Any idea as to when a patch might be forthcoming?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=494572&group_id=5470



From noreply@sourceforge.net  Thu May 23 23:10:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 May 2002 15:10:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-487297 ] Copy from stdout after crash
Message-ID: <E17B0mu-000752-00@usw-sf-web2.sourceforge.net>

Bugs item #487297, was opened at 2001-11-30 00:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487297&group_id=5470

Category: Macintosh
Group: Feature Request
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jack Jansen (jackjansen)
Summary: Copy from stdout after crash

Initial Comment:
It would be really nice if one could copy text from the stdout window (e.g. PythonInterpreter.out) after a crash. Apparently this now works in some cases, but still fails after a crash in a delay-console-window applet.

I am submitting this to SourceForge as per Jack Jansens' request.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-05-24 00:10

Message:
Logged In: YES 
user_id=45365

This probably won't get fixed in MacPython's lifetime, especially because in most cases Copy does work, it's only for delayed-console applets that there is a problem. People will have to use a screenshot or retype the traceback in that case, too bad.

----------------------------------------------------------------------

Comment By: Jurjen N.E. Bos (jneb)
Date: 2002-02-02 01:49

Message:
Logged In: YES 
user_id=446428

May be connected to the bug that I am about to submit on sys.stdout.flush().
- Jurjen

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-12-02 22:09

Message:
Logged In: YES 
user_id=45365

Lowered the priority.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487297&group_id=5470



From noreply@sourceforge.net  Thu May 23 23:18:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 May 2002 15:18:37 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-519227 ] hook method for 'is' operator
Message-ID: <E17B0ur-0000jO-00@usw-sf-web4.sourceforge.net>

Feature Requests item #519227, was opened at 2002-02-18 12:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=519227&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Dan Parisien (mathematician)
Assigned to: Nobody/Anonymous (nobody)
Summary: hook method for 'is' operator

Initial Comment:
Being able to overload the 'is' operator would lead 
to nicer more readable code:

# constant
Open = ("OPEN",)

# dummy class for my example
class File:
	id = 0
	def __init__(self, file=None):
		if file is not None:
			self.open(file)

	# overload 'is' operator
	def __is__(self, other):
		if id(self)==id(other): # default
			return 1
		elif other==("OPEN",) and self.id!=0:
			return 1
		return 0

	def open(self, file):
		self.id = open(file).fileno

f = File("myfile.txt")
if f is Open:
	print "File is open!"
else:
	print "File is not open"

'is not' could just test __is__ and return 'not 
retval'




----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-19 20:12

Message:
Logged In: YES 
user_id=31435

Unless I'm missing something intended,

x is y -> id(x)==id(y) or x.__is__(y)

is true whenever "x is y" is true today, but may be true 
even in cases where "x is y" is false today.  If so, it's 
not backward compatible, and general code relying on 
current semantics would still break.  For example, any kind 
of general code that's crawling over an object graph needs 
to know whether it's seen an object before, current "is" 
can and is used to answer that question precisely, and it's 
as bad to tell it that two distinct objects are identical 
as it is to tell it that two identical objects are 
distinct.  The standard copy.deepcopy() is one example 
of "general code that's crawling over an object graph".

OO languages with object identity really need a way to ask 
about object identity, and "is" has always been that way in 
Python (btw, "is" existed long before "id()" was 
introduced).  For that reason, if you write a PEP, I think 
you'd get farther by leaving "is" alone and proposing 
another spelling instead.

----------------------------------------------------------------------

Comment By: Dan Parisien (mathematician)
Date: 2002-02-19 09:33

Message:
Logged In: YES 
user_id=118203

what about:

x is y -> id(x)==id(y) or x.__is__(y)

than old code would not break & one could use is for more 
than just object identity equivalence. Of course if the 
two operands are the same object, then it always returns 
true.

I would rather see

if dbrow is empty:
	# do something

than

if dbrow.isEmpty():
	# do something

which is like java's string equivalency test
strvar.isequal("to another string").

This way an object could 'be' anything :) Hey, well maybe 
for Python 3000. If so, I also recommend adding an 
operator called 'is a' which is equivalent to isinstance() 
in current python.

if d is a dict:
	# do something


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-18 19:34

Message:
Logged In: YES 
user_id=31435

I'm afraid I agree with Neil that this would be a 
disaster.  There's code that absolutely depends on "is" 
meaning object identity.  One example (you'll find others 
if you just look for them):  _deepcopy_tuple() in the 
standard copy.py relies on it, in its second loop.  If the 
operator ever "lied" about object identity, the semantics 
of deep copies could break in amazing ways.  There's lots 
of "foundational" code in a similar boat (e.g., my own 
Cyclops.py replies on current "is" semantics all over the 
place, and that's an important example because it's not in 
the standard distribution:  we have no way to locate, let 
alone repair, all the code that would break).

If you want to pursue this, then because it's not backward 
compatible, it will require a PEP to propose the change and 
introduce a corresponding __future__ statement.

The other thing you'll get resistance on is that "is" is 
dirt cheap today, and some code relies on that too.  If it 
has to look for an object override, what's currently an 
exceptionally fast implementation:

	case PyCmp_IS:
	case PyCmp_IS_NOT:
		res = (v == w);
		if (op == (int) PyCmp_IS_NOT)
			res = !res;
		break;

will at least have to do new indirection dances too through 
the type objects (to see first whether either operand 
overrides "is").

----------------------------------------------------------------------

Comment By: Dan Parisien (mathematician)
Date: 2002-02-18 12:50

Message:
Logged In: YES 
user_id=118203

You can say the same for all the operators in python. The 
default behavior would be object identity, but:

x is y

is the same as doing

id(x)==id(y)

So the 'is' operator is actually superfluous except for 
its readability value.

Your comment seems to me like a knee jerk resistance to 
change. Now if you were to tell me that it would make 
python drastically slower or that it would be difficult to 
implement, then you would have a good point...



----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-02-18 12:30

Message:
Logged In: YES 
user_id=35752

The "is" operator has well defined semantics.  It compares
object identity.  Allowing it to be redefined would a terrible
idea, IMHO.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=519227&group_id=5470



From noreply@sourceforge.net  Thu May 23 23:18:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 May 2002 15:18:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-557482 ] _builtinSuites is ignored
Message-ID: <E17B0v4-00079h-00@usw-sf-web2.sourceforge.net>

Bugs item #557482, was opened at 2002-05-18 00:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557482&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alexandre Parenteau (aubonbeurre)
Assigned to: Jack Jansen (jackjansen)
Summary: _builtinSuites is ignored

Initial Comment:
_builtinSuites is ignored from the Makefile inside 
python/dist/src/Mac/OSX/Makefile.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-05-24 00:18

Message:
Logged In: YES 
user_id=45365

Fixed in Mac/OSX/Makefile 1.10

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557482&group_id=5470



From noreply@sourceforge.net  Thu May 23 23:25:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 May 2002 15:25:31 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-519227 ] hook method for 'is' operator
Message-ID: <E17B11X-00011R-00@usw-sf-web3.sourceforge.net>

Feature Requests item #519227, was opened at 2002-02-18 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=519227&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: None
Priority: 5
Submitted By: Dan Parisien (mathematician)
Assigned to: Nobody/Anonymous (nobody)
Summary: hook method for 'is' operator

Initial Comment:
Being able to overload the 'is' operator would lead 
to nicer more readable code:

# constant
Open = ("OPEN",)

# dummy class for my example
class File:
	id = 0
	def __init__(self, file=None):
		if file is not None:
			self.open(file)

	# overload 'is' operator
	def __is__(self, other):
		if id(self)==id(other): # default
			return 1
		elif other==("OPEN",) and self.id!=0:
			return 1
		return 0

	def open(self, file):
		self.id = open(file).fileno

f = File("myfile.txt")
if f is Open:
	print "File is open!"
else:
	print "File is not open"

'is not' could just test __is__ and return 'not 
retval'




----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-05-23 22:25

Message:
Logged In: YES 
user_id=35752

__eql__? :-P

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-20 01:12

Message:
Logged In: YES 
user_id=31435

Unless I'm missing something intended,

x is y -> id(x)==id(y) or x.__is__(y)

is true whenever "x is y" is true today, but may be true 
even in cases where "x is y" is false today.  If so, it's 
not backward compatible, and general code relying on 
current semantics would still break.  For example, any kind 
of general code that's crawling over an object graph needs 
to know whether it's seen an object before, current "is" 
can and is used to answer that question precisely, and it's 
as bad to tell it that two distinct objects are identical 
as it is to tell it that two identical objects are 
distinct.  The standard copy.deepcopy() is one example 
of "general code that's crawling over an object graph".

OO languages with object identity really need a way to ask 
about object identity, and "is" has always been that way in 
Python (btw, "is" existed long before "id()" was 
introduced).  For that reason, if you write a PEP, I think 
you'd get farther by leaving "is" alone and proposing 
another spelling instead.

----------------------------------------------------------------------

Comment By: Dan Parisien (mathematician)
Date: 2002-02-19 14:33

Message:
Logged In: YES 
user_id=118203

what about:

x is y -> id(x)==id(y) or x.__is__(y)

than old code would not break & one could use is for more 
than just object identity equivalence. Of course if the 
two operands are the same object, then it always returns 
true.

I would rather see

if dbrow is empty:
	# do something

than

if dbrow.isEmpty():
	# do something

which is like java's string equivalency test
strvar.isequal("to another string").

This way an object could 'be' anything :) Hey, well maybe 
for Python 3000. If so, I also recommend adding an 
operator called 'is a' which is equivalent to isinstance() 
in current python.

if d is a dict:
	# do something


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-19 00:34

Message:
Logged In: YES 
user_id=31435

I'm afraid I agree with Neil that this would be a 
disaster.  There's code that absolutely depends on "is" 
meaning object identity.  One example (you'll find others 
if you just look for them):  _deepcopy_tuple() in the 
standard copy.py relies on it, in its second loop.  If the 
operator ever "lied" about object identity, the semantics 
of deep copies could break in amazing ways.  There's lots 
of "foundational" code in a similar boat (e.g., my own 
Cyclops.py replies on current "is" semantics all over the 
place, and that's an important example because it's not in 
the standard distribution:  we have no way to locate, let 
alone repair, all the code that would break).

If you want to pursue this, then because it's not backward 
compatible, it will require a PEP to propose the change and 
introduce a corresponding __future__ statement.

The other thing you'll get resistance on is that "is" is 
dirt cheap today, and some code relies on that too.  If it 
has to look for an object override, what's currently an 
exceptionally fast implementation:

	case PyCmp_IS:
	case PyCmp_IS_NOT:
		res = (v == w);
		if (op == (int) PyCmp_IS_NOT)
			res = !res;
		break;

will at least have to do new indirection dances too through 
the type objects (to see first whether either operand 
overrides "is").

----------------------------------------------------------------------

Comment By: Dan Parisien (mathematician)
Date: 2002-02-18 17:50

Message:
Logged In: YES 
user_id=118203

You can say the same for all the operators in python. The 
default behavior would be object identity, but:

x is y

is the same as doing

id(x)==id(y)

So the 'is' operator is actually superfluous except for 
its readability value.

Your comment seems to me like a knee jerk resistance to 
change. Now if you were to tell me that it would make 
python drastically slower or that it would be difficult to 
implement, then you would have a good point...



----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-02-18 17:30

Message:
Logged In: YES 
user_id=35752

The "is" operator has well defined semantics.  It compares
object identity.  Allowing it to be redefined would a terrible
idea, IMHO.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=519227&group_id=5470



From noreply@sourceforge.net  Thu May 23 23:37:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 May 2002 15:37:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-492465 ] mkcwproject: custom __initialize routine
Message-ID: <E17B1Cf-0007NH-00@usw-sf-web2.sourceforge.net>

Bugs item #492465, was opened at 2001-12-13 15:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492465&group_id=5470

Category: Macintosh
Group: Feature Request
Status: Open
Resolution: None
Priority: 1
Submitted By: Just van Rossum (jvr)
>Assigned to: Just van Rossum (jvr)
Summary: mkcwproject: custom __initialize routine

Initial Comment:
Both for _Tkinter and CoreGraphics it is neccesary to
specify a custom fragment initializer. It would be nice
if this were doable with mkcwproject, as it would reduce
the number of CW project file under CVS by 4...

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-05-24 00:37

Message:
Logged In: YES 
user_id=45365

genpluginprojects has been modified to allow an optional initialize=xxx keyword argument (and its mkcwproject foundation too). The only thing I've tested is that it doesn't have any adverse effects on the existing projects that are built. Assigning it back to you so you can try to generate the CG project with it and remove the hand-built CG project file. If that all works assign it back to me and I'll do the same for Tkinter.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492465&group_id=5470



From noreply@sourceforge.net  Thu May 23 23:47:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 May 2002 15:47:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-559884 ] imaplib.IMAP4.open() typo
Message-ID: <E17B1MK-0007TV-00@usw-sf-web2.sourceforge.net>

Bugs item #559884, was opened at 2002-05-23 18:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559884&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: imaplib.IMAP4.open() typo

Initial Comment:
Looking at imaplib.py, class IMAP4, method open(),
there are two arguments, host and port, which are never
used in the method.  Instead, self.host and self.port
(set only in __init__) are used.  This gives a
misleading notion of what open() does.  I suggest that
these arguments be removed, because currently an IMAP4
object cannot be open()ed later by an external user,
i.e., open() is really private.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559884&group_id=5470



From noreply@sourceforge.net  Fri May 24 10:53:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 02:53:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-548651 ] Fix the METH_CLASS implementation
Message-ID: <E17BBlN-0005YO-00@usw-sf-web2.sourceforge.net>

Bugs item #548651, was opened at 2002-04-25 17:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 7
Submitted By: Thomas Heller (theller)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Fix the METH_CLASS implementation

Initial Comment:
The devel-docs about METH_CLASS:

The method will be passed the type object as the first 
parameter rather than an instance of the type. This is 
used to create class methods, similar to what is 
created when using the classmethod() built-in 
function. New in version 2.3.

The code does not do it in this way. The first 
parameter the function receives is NULL, the type 
object goes together with the remaining arguments
in the second parameter (which is a tuple).

See the thread with subject 'METH_CLASS' on python-dev 
at 2002-04-25, Guido agreed that this should be fixed.


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2002-05-24 11:53

Message:
Logged In: YES 
user_id=11105

IMO this should be fixed before 2.3 is released, so I'm
raising the priority to 7.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470



From noreply@sourceforge.net  Fri May 24 12:59:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 04:59:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-560064 ] inconsistent behavior of __getslice__
Message-ID: <E17BDjc-00007P-00@usw-sf-web4.sourceforge.net>

Bugs item #560064, was opened at 2002-05-24 13:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cesar Douady (douady)
Assigned to: Nobody/Anonymous (nobody)
Summary: inconsistent behavior of __getslice__

Initial Comment:
The following trace shows what I mean:
>>> help(str.__getslice__)
Help on wrapper_descriptor:

__getslice__(...)
    x.__getslice__(i, j) <==> x[i:j]
>>> 'ab'[-1]
'b'
>>> 'ab'.__getitem__(-1)
'b'
>>> 'ab'[-2:-1]
'a'
>>> 'ab'.__getslice__(-2,-1)
''

that is, __getslice__ does not add the length of the
sequence to its arguments when they are negative as
indexing with [:] does.
This contradicts the docstring which says __getslice__
is equivalent to indexing.
The same behavior applies to lists.

Note that __getitem__ does it right.

This bug may be linked to bug 473985 ('str, __getitem__
and slices') but should be much easier to fix.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470



From noreply@sourceforge.net  Fri May 24 13:14:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 05:14:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-560064 ] inconsistent behavior of __getslice__
Message-ID: <E17BDxf-0000Bp-00@usw-sf-web4.sourceforge.net>

Bugs item #560064, was opened at 2002-05-24 06:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cesar Douady (douady)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: inconsistent behavior of __getslice__

Initial Comment:
The following trace shows what I mean:
>>> help(str.__getslice__)
Help on wrapper_descriptor:

__getslice__(...)
    x.__getslice__(i, j) <==> x[i:j]
>>> 'ab'[-1]
'b'
>>> 'ab'.__getitem__(-1)
'b'
>>> 'ab'[-2:-1]
'a'
>>> 'ab'.__getslice__(-2,-1)
''

that is, __getslice__ does not add the length of the
sequence to its arguments when they are negative as
indexing with [:] does.
This contradicts the docstring which says __getslice__
is equivalent to indexing.
The same behavior applies to lists.

Note that __getitem__ does it right.

This bug may be linked to bug 473985 ('str, __getitem__
and slices') but should be much easier to fix.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470



From noreply@sourceforge.net  Fri May 24 13:58:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 05:58:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-560064 ] inconsistent behavior of __getslice__
Message-ID: <E17BEeb-00012N-00@usw-sf-web3.sourceforge.net>

Bugs item #560064, was opened at 2002-05-24 06:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Cesar Douady (douady)
>Assigned to: Tim Peters (tim_one)
Summary: inconsistent behavior of __getslice__

Initial Comment:
The following trace shows what I mean:
>>> help(str.__getslice__)
Help on wrapper_descriptor:

__getslice__(...)
    x.__getslice__(i, j) <==> x[i:j]
>>> 'ab'[-1]
'b'
>>> 'ab'.__getitem__(-1)
'b'
>>> 'ab'[-2:-1]
'a'
>>> 'ab'.__getslice__(-2,-1)
''

that is, __getslice__ does not add the length of the
sequence to its arguments when they are negative as
indexing with [:] does.
This contradicts the docstring which says __getslice__
is equivalent to indexing.
The same behavior applies to lists.

Note that __getitem__ does it right.

This bug may be linked to bug 473985 ('str, __getitem__
and slices') but should be much easier to fix.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-24 07:58

Message:
Logged In: YES 
user_id=80475

Tim,  I attached a tiny patch which fixes the behavior for 
strings.  I've also tried out the same change in listobject.c 
and unicodeobject.c.  Is this the right this to do or are 
there more subtleties to this than meet the eye?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560064&group_id=5470



From noreply@sourceforge.net  Fri May 24 15:36:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 07:36:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-559884 ] imaplib.IMAP4.open() typo
Message-ID: <E17BGBK-00018i-00@usw-sf-web4.sourceforge.net>

Bugs item #559884, was opened at 2002-05-23 17:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559884&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: imaplib.IMAP4.open() typo

Initial Comment:
Looking at imaplib.py, class IMAP4, method open(),
there are two arguments, host and port, which are never
used in the method.  Instead, self.host and self.port
(set only in __init__) are used.  This gives a
misleading notion of what open() does.  I suggest that
these arguments be removed, because currently an IMAP4
object cannot be open()ed later by an external user,
i.e., open() is really private.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-24 09:36

Message:
Logged In: YES 
user_id=80475

The two arguments are needed because open() can be 
overridden in a sub-class.

Suggest testing to see if arguments are supplied and using 
them instead of self.host and self.port.  See attached 
patch.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559884&group_id=5470



From noreply@sourceforge.net  Fri May 24 17:15:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 09:15:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-560215 ] PyType_IsSubtype can segfault
Message-ID: <E17BHjL-0007Cp-00@usw-sf-web1.sourceforge.net>

Bugs item #560215, was opened at 2002-05-24 16:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560215&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Barrett (barrett)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyType_IsSubtype can segfault

Initial Comment:
I have a C extension that uses PyList_Check. Sometimes
the pointer being checked is not a real Python object,
so ob->ob_type might be NULL. Under Python 2.1 and
early, this simple macro would handle this case without
problems. Under Python 2.2, this case will cause Python
to segfault.

This occurs because PyList_Check under Python 2.2 has
changed and includes PyType_IsSubtype which assumes
that both of its arguments are Python type objects. If
this is not the case, then all hell can break loose,
which in my case happens when the first argument is a
NULL pointer.

My use of PyList_Check may not be good programming, but
this change in PyList_Check and other such object
checks has radically changed the behavior of these
macros. In Python 2.1 and early, they were simply
pointer comparisons: it was that object or it wasn't.
Now these pointers must be Python objects for these
macros to work. Otherwise Python is likely to crash.

I can change my code and probably should, but this
issue should be considered in some detail because of
its wide ramifications on Python extension programming.
This change really begs for a Pointer Object in Python
which wraps a C pointer.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560215&group_id=5470



From noreply@sourceforge.net  Fri May 24 17:33:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 09:33:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-560215 ] PyType_IsSubtype can segfault
Message-ID: <E17BI0C-0000Qh-00@usw-sf-web2.sourceforge.net>

Bugs item #560215, was opened at 2002-05-24 12:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560215&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Barrett (barrett)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyType_IsSubtype can segfault

Initial Comment:
I have a C extension that uses PyList_Check. Sometimes
the pointer being checked is not a real Python object,
so ob->ob_type might be NULL. Under Python 2.1 and
early, this simple macro would handle this case without
problems. Under Python 2.2, this case will cause Python
to segfault.

This occurs because PyList_Check under Python 2.2 has
changed and includes PyType_IsSubtype which assumes
that both of its arguments are Python type objects. If
this is not the case, then all hell can break loose,
which in my case happens when the first argument is a
NULL pointer.

My use of PyList_Check may not be good programming, but
this change in PyList_Check and other such object
checks has radically changed the behavior of these
macros. In Python 2.1 and early, they were simply
pointer comparisons: it was that object or it wasn't.
Now these pointers must be Python objects for these
macros to work. Otherwise Python is likely to crash.

I can change my code and probably should, but this
issue should be considered in some detail because of
its wide ramifications on Python extension programming.
This change really begs for a Pointer Object in Python
which wraps a C pointer.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-05-24 12:33

Message:
Logged In: YES 
user_id=31435

Sorry, your code was never legitimate.  If you got away with 
passing non-object pointers to PyList_Check before, all 
that says is that the HW you were running on didn't happen 
to raise bus errors for trying to read up an op->ob_type 
pointer where it didn't exist.  IOW, PyList_Check was 
never "simply a pointer comparison":  it always first had to 
*read up* a pointer-aligned value at an offset *from* the 
argument pointer.  I suppose you're running on Intel boxes, 
where misaligned reads aren't fatal.

Note too that PyList_Check is documented as requiring a 
PyObject* argument.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560215&group_id=5470



From noreply@sourceforge.net  Fri May 24 20:15:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 12:15:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-559429 ] __gxx_personality_v0 not found by ld
Message-ID: <E17BKXS-0000kR-00@usw-sf-web1.sourceforge.net>

Bugs item #559429, was opened at 2002-05-22 17:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559429&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: george r. goffe (grgoffe)
Assigned to: Nobody/Anonymous (nobody)
Summary: __gxx_personality_v0 not found by ld

Initial Comment:

Howdy,

I'm building Python-2.2.1 on a solaris 2.8 system and
am having trouble. The loader can not find the above
named external reference.

I'm enclosing the build log that shows (probably) more
than you ever wanted to know but it DOES show the
problem.

Any/all help/hints/tips would be appreciated.

Regards,

George...

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-24 12:15

Message:
Logged In: NO 

Hi,

I'm looking at the same problem in the same environment.

I could fix the failed compilation by changing gcc by g++,
which means that the --with-cxx=g++ option passed to
configure did not have the expected effect.

Regards,

R. Berber


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559429&group_id=5470



From noreply@sourceforge.net  Fri May 24 20:36:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 12:36:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
Message-ID: <E17BKrg-00042L-00@usw-sf-web4.sourceforge.net>

Bugs item #210682, was opened at 2000-07-31 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Later
>Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb can only step when at botframe (PR#4)

Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 15:36

Message:
Logged In: YES 
user_id=6380

You know, I cannot reproduce the problem!

I created this module:

import pdb
def foo():
    x = 12
    y = 2
    z = x**y
    print z
    return
pdb.set_trace()
print 12
print "hello world"
foo()

When I run it I get the pdb prompt.
When I hit "continue" at the prompt,
the whole program executes.

Before we start messing with this
I'd like to be able to reproduce
the problem so I can confirm that
it goes away!

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-23 16:55

Message:
Logged In: YES 
user_id=105700

There appears to be a simple solution.
I'm not used to pdb very much, so I cannot fur sure
say that my patch doesn't affect any extension of it,
but it seems to work just fine.

Idea: Allow botframe not to be a frame at all, but also None.
This makes it possible to use f_back in line 67:
            self.botframe = frame.f_back ##!!CT
In stop_here, we just omit the first two lines:
    def stop_here(self, frame):
        ##!!CT if self.stopframe is None:
        ##!!CT     return 1
        if frame is self.stopframe:
            return 1
        while frame is not None and frame is not self.stopframe:
            if frame is self.botframe:
                return 1
            frame = frame.f_back
        return 0

By this trick, botframe is llowed to be one level "on top"
of the
topmost frame, and we see the topmost frame behave as nicely
as every other.

-- chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:55

Message:
Logged In: YES 
user_id=6380

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:30

Message:
Logged In: YES 
user_id=31392

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:19

Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:18

Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470



From noreply@sourceforge.net  Fri May 24 20:50:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 12:50:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-560286 ] Add docs for 'string'
Message-ID: <E17BL5F-0004C0-00@usw-sf-web4.sourceforge.net>

Bugs item #560286, was opened at 2002-05-24 15:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560286&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Add docs for 'string'

Initial Comment:
Please document the new built-in abstract type
'string'.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560286&group_id=5470



From noreply@sourceforge.net  Fri May 24 22:10:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 14:10:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-551412 ] possible to fail to calc mro's
Message-ID: <E17BMKC-00055E-00@usw-sf-web4.sourceforge.net>

Bugs item #551412, was opened at 2002-05-02 09:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: possible to fail to calc mro's

Initial Comment:
This only crashes on the release22-maint branch, and
only when coredump is true:

class UserLong(object):
    def __pow__(self, *args):
        pass

coredump = 1

if not coredump:
   int.__mro__

pow(0, UserLong(), 0)

It's the type of the first argument to pow() that's
relavent: if you change it to "pow(0L, UserLong(), 0)"
you then have to change "int.__mro__" to "long.__mro__"
to avoid the crash.

Maybe it was the "typeobject.c refactoring" patch that
accidentally fixed this on the trunk?

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:10

Message:
Logged In: YES 
user_id=6380

Hm, this is serious.

This can happen whenever a built-in type
isn't initialized by PyType_Ready() yet,
and for many that is pretty common.
(The call to int.__mro__ goes through
type_getattro which calls PyType_Ready().)

I'm not sure which refactoring patch
you are referring to, and I'm actually
not at all sure that this can't happen
in 2.3 (despite the fact that this
particular example doesn't core dump there).

I'll investigate more...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470



From noreply@sourceforge.net  Fri May 24 22:20:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 14:20:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-551412 ] possible to fail to calc mro's
Message-ID: <E17BMTx-0002AR-00@usw-sf-web1.sourceforge.net>

Bugs item #551412, was opened at 2002-05-02 09:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 6
Submitted By: Michael Hudson (mwh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: possible to fail to calc mro's

Initial Comment:
This only crashes on the release22-maint branch, and
only when coredump is true:

class UserLong(object):
    def __pow__(self, *args):
        pass

coredump = 1

if not coredump:
   int.__mro__

pow(0, UserLong(), 0)

It's the type of the first argument to pow() that's
relavent: if you change it to "pow(0L, UserLong(), 0)"
you then have to change "int.__mro__" to "long.__mro__"
to avoid the crash.

Maybe it was the "typeobject.c refactoring" patch that
accidentally fixed this on the trunk?

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:20

Message:
Logged In: YES 
user_id=6380

In fact, this still crashes in 2.2:
pow(0L, UserLong(), 0L)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:10

Message:
Logged In: YES 
user_id=6380

Hm, this is serious.

This can happen whenever a built-in type
isn't initialized by PyType_Ready() yet,
and for many that is pretty common.
(The call to int.__mro__ goes through
type_getattro which calls PyType_Ready().)

I'm not sure which refactoring patch
you are referring to, and I'm actually
not at all sure that this can't happen
in 2.3 (despite the fact that this
particular example doesn't core dump there).

I'll investigate more...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470



From noreply@sourceforge.net  Fri May 24 22:42:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 14:42:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-551412 ] possible to fail to calc mro's
Message-ID: <E17BMpZ-0002PM-00@usw-sf-web1.sourceforge.net>

Bugs item #551412, was opened at 2002-05-02 09:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470

Category: Python Interpreter Core
>Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Michael Hudson (mwh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: possible to fail to calc mro's

Initial Comment:
This only crashes on the release22-maint branch, and
only when coredump is true:

class UserLong(object):
    def __pow__(self, *args):
        pass

coredump = 1

if not coredump:
   int.__mro__

pow(0, UserLong(), 0)

It's the type of the first argument to pow() that's
relavent: if you change it to "pow(0L, UserLong(), 0)"
you then have to change "int.__mro__" to "long.__mro__"
to avoid the crash.

Maybe it was the "typeobject.c refactoring" patch that
accidentally fixed this on the trunk?

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:42

Message:
Logged In: YES 
user_id=6380

OK, I nailed it.

The fix is to call PyType_Ready()
in _PyType_Lookup() when mro is NULL.

Fixed in both 2.3 and 2.2.
A test case added only for 2.3.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:20

Message:
Logged In: YES 
user_id=6380

In fact, this still crashes in 2.2:
pow(0L, UserLong(), 0L)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:10

Message:
Logged In: YES 
user_id=6380

Hm, this is serious.

This can happen whenever a built-in type
isn't initialized by PyType_Ready() yet,
and for many that is pretty common.
(The call to int.__mro__ goes through
type_getattro which calls PyType_Ready().)

I'm not sure which refactoring patch
you are referring to, and I'm actually
not at all sure that this can't happen
in 2.3 (despite the fact that this
particular example doesn't core dump there).

I'll investigate more...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470



From noreply@sourceforge.net  Fri May 24 22:46:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 14:46:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-551412 ] possible to fail to calc mro's
Message-ID: <E17BMt7-0003pf-00@usw-sf-web2.sourceforge.net>

Bugs item #551412, was opened at 2002-05-02 09:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Open
Resolution: Fixed
Priority: 6
Submitted By: Michael Hudson (mwh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: possible to fail to calc mro's

Initial Comment:
This only crashes on the release22-maint branch, and
only when coredump is true:

class UserLong(object):
    def __pow__(self, *args):
        pass

coredump = 1

if not coredump:
   int.__mro__

pow(0, UserLong(), 0)

It's the type of the first argument to pow() that's
relavent: if you change it to "pow(0L, UserLong(), 0)"
you then have to change "int.__mro__" to "long.__mro__"
to avoid the crash.

Maybe it was the "typeobject.c refactoring" patch that
accidentally fixed this on the trunk?

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:46

Message:
Logged In: YES 
user_id=6380

Argh, reopening.

There's one little detail left:
_PyType_Lookup() promises not
to set an exception.  If the call
to PyType_Ready() fails, this
promise is broken...

What to do?  PyErr_Clear()
and return NULL comes to mind...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:42

Message:
Logged In: YES 
user_id=6380

OK, I nailed it.

The fix is to call PyType_Ready()
in _PyType_Lookup() when mro is NULL.

Fixed in both 2.3 and 2.2.
A test case added only for 2.3.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:20

Message:
Logged In: YES 
user_id=6380

In fact, this still crashes in 2.2:
pow(0L, UserLong(), 0L)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:10

Message:
Logged In: YES 
user_id=6380

Hm, this is serious.

This can happen whenever a built-in type
isn't initialized by PyType_Ready() yet,
and for many that is pretty common.
(The call to int.__mro__ goes through
type_getattro which calls PyType_Ready().)

I'm not sure which refactoring patch
you are referring to, and I'm actually
not at all sure that this can't happen
in 2.3 (despite the fact that this
particular example doesn't core dump there).

I'll investigate more...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470



From noreply@sourceforge.net  Sat May 25 05:17:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 May 2002 21:17:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
Message-ID: <E17BT03-00015s-00@usw-sf-web4.sourceforge.net>

Bugs item #210682, was opened at 2000-08-01 07:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Later
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb can only step when at botframe (PR#4)

Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-05-25 14:17

Message:
Logged In: YES 
user_id=14198

This appears to have been fixed magically in Python 2.2. 
Using Python 2.1 with the sample demonstrates the bug, while
2.2 and current CVS both work correctly.  Haven't tried 2.1.1

A scan of the pdb and bdb logs don't show an obvious
candidate that fixed the bug, but to be quite honest, I
don't care *how* it was fixed now that it is <wink>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-25 05:36

Message:
Logged In: YES 
user_id=6380

You know, I cannot reproduce the problem!

I created this module:

import pdb
def foo():
    x = 12
    y = 2
    z = x**y
    print z
    return
pdb.set_trace()
print 12
print "hello world"
foo()

When I run it I get the pdb prompt.
When I hit "continue" at the prompt,
the whole program executes.

Before we start messing with this
I'd like to be able to reproduce
the problem so I can confirm that
it goes away!

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-24 06:55

Message:
Logged In: YES 
user_id=105700

There appears to be a simple solution.
I'm not used to pdb very much, so I cannot fur sure
say that my patch doesn't affect any extension of it,
but it seems to work just fine.

Idea: Allow botframe not to be a frame at all, but also None.
This makes it possible to use f_back in line 67:
            self.botframe = frame.f_back ##!!CT
In stop_here, we just omit the first two lines:
    def stop_here(self, frame):
        ##!!CT if self.stopframe is None:
        ##!!CT     return 1
        if frame is self.stopframe:
            return 1
        while frame is not None and frame is not self.stopframe:
            if frame is self.botframe:
                return 1
            frame = frame.f_back
        return 0

By this trick, botframe is llowed to be one level "on top"
of the
topmost frame, and we see the topmost frame behave as nicely
as every other.

-- chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-02 09:55

Message:
Logged In: YES 
user_id=6380

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-02 09:30

Message:
Logged In: YES 
user_id=31392

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-18 01:19

Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-18 01:18

Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470



From noreply@sourceforge.net  Sat May 25 09:59:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 25 May 2002 01:59:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-560438 ] foo() doesn't use __getattribute__
Message-ID: <E17BXOx-0000ja-00@usw-sf-web1.sourceforge.net>

Bugs item #560438, was opened at 2002-05-25 08:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560438&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Nobody/Anonymous (nobody)
Summary: foo() doesn't use __getattribute__

Initial Comment:
In the Python 2.2 release notes, it says::

- For new-style classes, what was previously called
__getattr__ is now
  called __getattribute__.  This method, if defined, is
called for
  *every* attribute access.  

However, if I define a callable class that also defines
a __getattribute__ method, the __getattribute__ method
is not used when I say instance().

class Foo(object):

    def __getattribute__(self, name):
        print "__getattribute__ with name =",name
        if name=="__call__":
            return lambda:1
        object.__getattribute__(self, name)

    def __call__(self):
        print "__call__ method called"
        
f = Foo()
f.__call__()
f()

$ python /tmp/test.py
__getattribute__ with name = __call__
__call__ method called

I would expect the second line of output to be the same
as the first.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560438&group_id=5470



From noreply@sourceforge.net  Sat May 25 10:05:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 25 May 2002 02:05:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-560438 ] foo() doesn't use __getattribute__
Message-ID: <E17BXUO-0000nr-00@usw-sf-web1.sourceforge.net>

Bugs item #560438, was opened at 2002-05-25 08:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560438&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Nobody/Anonymous (nobody)
Summary: foo() doesn't use __getattribute__

Initial Comment:
In the Python 2.2 release notes, it says::

- For new-style classes, what was previously called
__getattr__ is now
  called __getattribute__.  This method, if defined, is
called for
  *every* attribute access.  

However, if I define a callable class that also defines
a __getattribute__ method, the __getattribute__ method
is not used when I say instance().

class Foo(object):

    def __getattribute__(self, name):
        print "__getattribute__ with name =",name
        if name=="__call__":
            return lambda:1
        object.__getattribute__(self, name)

    def __call__(self):
        print "__call__ method called"
        
f = Foo()
f.__call__()
f()

$ python /tmp/test.py
__getattribute__ with name = __call__
__call__ method called

I would expect the second line of output to be the same
as the first.

----------------------------------------------------------------------

>Comment By: Steve Alexander (stevea_zope)
Date: 2002-05-25 09:05

Message:
Logged In: YES 
user_id=492001

Properly formatted test case in uploaded file.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560438&group_id=5470



From noreply@sourceforge.net  Sat May 25 12:56:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 25 May 2002 04:56:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
Message-ID: <E17Ba9b-0002gg-00@usw-sf-web1.sourceforge.net>

Bugs item #210682, was opened at 2000-07-31 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb can only step when at botframe (PR#4)

Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-25 07:56

Message:
Logged In: YES 
user_id=6380

OK, closing.  Christian: please *don't* check it it!

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-05-25 00:17

Message:
Logged In: YES 
user_id=14198

This appears to have been fixed magically in Python 2.2. 
Using Python 2.1 with the sample demonstrates the bug, while
2.2 and current CVS both work correctly.  Haven't tried 2.1.1

A scan of the pdb and bdb logs don't show an obvious
candidate that fixed the bug, but to be quite honest, I
don't care *how* it was fixed now that it is <wink>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 15:36

Message:
Logged In: YES 
user_id=6380

You know, I cannot reproduce the problem!

I created this module:

import pdb
def foo():
    x = 12
    y = 2
    z = x**y
    print z
    return
pdb.set_trace()
print 12
print "hello world"
foo()

When I run it I get the pdb prompt.
When I hit "continue" at the prompt,
the whole program executes.

Before we start messing with this
I'd like to be able to reproduce
the problem so I can confirm that
it goes away!

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-23 16:55

Message:
Logged In: YES 
user_id=105700

There appears to be a simple solution.
I'm not used to pdb very much, so I cannot fur sure
say that my patch doesn't affect any extension of it,
but it seems to work just fine.

Idea: Allow botframe not to be a frame at all, but also None.
This makes it possible to use f_back in line 67:
            self.botframe = frame.f_back ##!!CT
In stop_here, we just omit the first two lines:
    def stop_here(self, frame):
        ##!!CT if self.stopframe is None:
        ##!!CT     return 1
        if frame is self.stopframe:
            return 1
        while frame is not None and frame is not self.stopframe:
            if frame is self.botframe:
                return 1
            frame = frame.f_back
        return 0

By this trick, botframe is llowed to be one level "on top"
of the
topmost frame, and we see the topmost frame behave as nicely
as every other.

-- chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:55

Message:
Logged In: YES 
user_id=6380

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:30

Message:
Logged In: YES 
user_id=31392

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:19

Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:18

Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470



From noreply@sourceforge.net  Sat May 25 14:34:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 25 May 2002 06:34:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-557436 ] TclError is a str should be an Exception
Message-ID: <E17Bbgs-0003mw-00@usw-sf-web1.sourceforge.net>

Bugs item #557436, was opened at 2002-05-17 16:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557436&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: TclError is a str should be an Exception

Initial Comment:
Since string exceptions are deprecated, it seems that
TclError (in _tkinter.c) should be changed to derive
from Exception.

It isn't apparent to me how to accomplish this.  If
someone can provide a quick high-level description, I
can make a patch.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-25 09:34

Message:
Logged In: YES 
user_id=33168

The attached patch seems to work,
but I'm not sure I'm exercising it appropriately.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-22 12:56

Message:
Logged In: YES 
user_id=21627

The official API is PyErr_NewException, where NULL as the
base class indicates to inherit from Exception.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 04:45

Message:
Logged In: YES 
user_id=80475

Try makeclass() in Python/exceptions.c -- the file also 
shows how all the built-in exceptions get created.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=557436&group_id=5470



From noreply@sourceforge.net  Sun May 26 09:58:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 May 2002 01:58:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
Message-ID: <E17Btql-0002N1-00@usw-sf-web3.sourceforge.net>

Bugs item #210682, was opened at 2000-07-31 23:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb can only step when at botframe (PR#4)

Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

----------------------------------------------------------------------

>Comment By: Christian Tismer (tismer)
Date: 2002-05-26 10:58

Message:
Logged In: YES 
user_id=105700

Ok, I didn't check ti in, but I disagree to close it!
Do you think I would supply a patch if there weren't a problem?

The problem was reported to me by an IronPort Python
user who simply had the problem that pdb.runcall
on a given function *does not* run, but always single steps.
Your test doesn't get at the problem, since you don't set a
breakpoint, which is necessary to make it show up!

Here we go:
- write a simple program with some 10 lines
- start it with runcall
- set a breakpoint
- continue

and it will definately step!

With my patch, it works as expected.
Furthermore, Mark's F5 command is documented to
"start the program in the debugger". It never did so.
With the patch, it does.
Let's bring it to the end it deserves.

regards - chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-25 13:56

Message:
Logged In: YES 
user_id=6380

OK, closing.  Christian: please *don't* check it it!

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-05-25 06:17

Message:
Logged In: YES 
user_id=14198

This appears to have been fixed magically in Python 2.2. 
Using Python 2.1 with the sample demonstrates the bug, while
2.2 and current CVS both work correctly.  Haven't tried 2.1.1

A scan of the pdb and bdb logs don't show an obvious
candidate that fixed the bug, but to be quite honest, I
don't care *how* it was fixed now that it is <wink>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 21:36

Message:
Logged In: YES 
user_id=6380

You know, I cannot reproduce the problem!

I created this module:

import pdb
def foo():
    x = 12
    y = 2
    z = x**y
    print z
    return
pdb.set_trace()
print 12
print "hello world"
foo()

When I run it I get the pdb prompt.
When I hit "continue" at the prompt,
the whole program executes.

Before we start messing with this
I'd like to be able to reproduce
the problem so I can confirm that
it goes away!

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-23 22:55

Message:
Logged In: YES 
user_id=105700

There appears to be a simple solution.
I'm not used to pdb very much, so I cannot fur sure
say that my patch doesn't affect any extension of it,
but it seems to work just fine.

Idea: Allow botframe not to be a frame at all, but also None.
This makes it possible to use f_back in line 67:
            self.botframe = frame.f_back ##!!CT
In stop_here, we just omit the first two lines:
    def stop_here(self, frame):
        ##!!CT if self.stopframe is None:
        ##!!CT     return 1
        if frame is self.stopframe:
            return 1
        while frame is not None and frame is not self.stopframe:
            if frame is self.botframe:
                return 1
            frame = frame.f_back
        return 0

By this trick, botframe is llowed to be one level "on top"
of the
topmost frame, and we see the topmost frame behave as nicely
as every other.

-- chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 23:55

Message:
Logged In: YES 
user_id=6380

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:30

Message:
Logged In: YES 
user_id=31392

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 16:19

Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 16:18

Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470



From noreply@sourceforge.net  Sun May 26 20:15:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 May 2002 12:15:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-560794 ] deepcopy can't handle custom metaclasses
Message-ID: <E17C3U9-0002Ug-00@usw-sf-web3.sourceforge.net>

Bugs item #560794, was opened at 2002-05-26 11:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560794&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: deepcopy can't handle custom metaclasses

Initial Comment:
This is essentially the same problem as that reported in 
bug 494904 for pickle: deepcopy should treat instances 
of custom metaclasses the same way it treats 
instances of type 'type'.  I've attached a provisional fix 
which is basically a copy of the patch made to pickle (it 
checks to see if the type of the thing being deepcopied 
is a subclass of type).

One question: it seems to me that the exception 
handling code is unnecessary both here and in the 
pickle module.  In both cases, the first parameter to 
subclass is the result of a call to 'type' and the second 
is type 'type' itself, so it doesn't seem like there's any 
reason to worry about a TypeError.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560794&group_id=5470



From noreply@sourceforge.net  Sun May 26 20:35:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 May 2002 12:35:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-560794 ] deepcopy can't handle custom metaclasses
Message-ID: <E17C3o7-0008MW-00@usw-sf-web2.sourceforge.net>

Bugs item #560794, was opened at 2002-05-26 11:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560794&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: deepcopy can't handle custom metaclasses

Initial Comment:
This is essentially the same problem as that reported in 
bug 494904 for pickle: deepcopy should treat instances 
of custom metaclasses the same way it treats 
instances of type 'type'.  I've attached a provisional fix 
which is basically a copy of the patch made to pickle (it 
checks to see if the type of the thing being deepcopied 
is a subclass of type).

One question: it seems to me that the exception 
handling code is unnecessary both here and in the 
pickle module.  In both cases, the first parameter to 
subclass is the result of a call to 'type' and the second 
is type 'type' itself, so it doesn't seem like there's any 
reason to worry about a TypeError.

----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2002-05-26 11:35

Message:
Logged In: YES 
user_id=86307

I changed the patch so that issubclass is called before the 
attempt to access __deepcopy__ (to avoid unbound instance 
method problem methioned in 494904).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560794&group_id=5470



From noreply@sourceforge.net  Mon May 27 13:27:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 May 2002 05:27:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-561047 ] Maximum recursion limit exceeded
Message-ID: <E17CJan-000501-00@usw-sf-web3.sourceforge.net>

Bugs item #561047, was opened at 2002-05-27 12:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561047&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Gritsch (markus_gritsch)
Assigned to: Fredrik Lundh (effbot)
Summary: Maximum recursion limit exceeded

Initial Comment:
Hi!

I think I discovered a limitation of the "new" Regular
Expression engine.  I
have put together an example which shows the behavior at
 
http://stud4.tuwien.ac.at/~e9326522/temporary/re_bug_example.zip
(69kB)

When the script is run with Python 1.5.2 by invoking
  psmergeNS.py *.ps

everything is fine and it produces a merged output file
containing both
PostScript files.

When using Python 2.x the following Exception is raised:

  Traceback (most recent call last):
    File "psmergeNS4.py", line 35, in ?
      pages = theRE.findall(contents)
  RuntimeError: maximum recursion limit exceeded

This behavior is the same with the Linux and the Win32
version of Python.

Markus



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561047&group_id=5470



From noreply@sourceforge.net  Mon May 27 18:11:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 May 2002 10:11:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
Message-ID: <E17CO1s-0003Ux-00@usw-sf-web1.sourceforge.net>

Bugs item #210682, was opened at 2000-07-31 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb can only step when at botframe (PR#4)

Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-27 13:11

Message:
Logged In: YES 
user_id=6380

Can you be more specific in your example?
I don't understand how I start a 10-line
program with runcall, since runcall requires
a function.
I also want to know exactly which syntax
you use to set the breakpoint.

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-26 04:58

Message:
Logged In: YES 
user_id=105700

Ok, I didn't check ti in, but I disagree to close it!
Do you think I would supply a patch if there weren't a problem?

The problem was reported to me by an IronPort Python
user who simply had the problem that pdb.runcall
on a given function *does not* run, but always single steps.
Your test doesn't get at the problem, since you don't set a
breakpoint, which is necessary to make it show up!

Here we go:
- write a simple program with some 10 lines
- start it with runcall
- set a breakpoint
- continue

and it will definately step!

With my patch, it works as expected.
Furthermore, Mark's F5 command is documented to
"start the program in the debugger". It never did so.
With the patch, it does.
Let's bring it to the end it deserves.

regards - chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-25 07:56

Message:
Logged In: YES 
user_id=6380

OK, closing.  Christian: please *don't* check it it!

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-05-25 00:17

Message:
Logged In: YES 
user_id=14198

This appears to have been fixed magically in Python 2.2. 
Using Python 2.1 with the sample demonstrates the bug, while
2.2 and current CVS both work correctly.  Haven't tried 2.1.1

A scan of the pdb and bdb logs don't show an obvious
candidate that fixed the bug, but to be quite honest, I
don't care *how* it was fixed now that it is <wink>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 15:36

Message:
Logged In: YES 
user_id=6380

You know, I cannot reproduce the problem!

I created this module:

import pdb
def foo():
    x = 12
    y = 2
    z = x**y
    print z
    return
pdb.set_trace()
print 12
print "hello world"
foo()

When I run it I get the pdb prompt.
When I hit "continue" at the prompt,
the whole program executes.

Before we start messing with this
I'd like to be able to reproduce
the problem so I can confirm that
it goes away!

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-23 16:55

Message:
Logged In: YES 
user_id=105700

There appears to be a simple solution.
I'm not used to pdb very much, so I cannot fur sure
say that my patch doesn't affect any extension of it,
but it seems to work just fine.

Idea: Allow botframe not to be a frame at all, but also None.
This makes it possible to use f_back in line 67:
            self.botframe = frame.f_back ##!!CT
In stop_here, we just omit the first two lines:
    def stop_here(self, frame):
        ##!!CT if self.stopframe is None:
        ##!!CT     return 1
        if frame is self.stopframe:
            return 1
        while frame is not None and frame is not self.stopframe:
            if frame is self.botframe:
                return 1
            frame = frame.f_back
        return 0

By this trick, botframe is llowed to be one level "on top"
of the
topmost frame, and we see the topmost frame behave as nicely
as every other.

-- chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:55

Message:
Logged In: YES 
user_id=6380

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:30

Message:
Logged In: YES 
user_id=31392

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:19

Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:18

Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470



From noreply@sourceforge.net  Tue May 28 00:44:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 May 2002 16:44:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
Message-ID: <E17CUAR-0001r0-00@usw-sf-web4.sourceforge.net>

Bugs item #210682, was opened at 2000-07-31 23:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb can only step when at botframe (PR#4)

Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

----------------------------------------------------------------------

>Comment By: Christian Tismer (tismer)
Date: 2002-05-28 01:44

Message:
Logged In: YES 
user_id=105700

# test program for bdb buglet.
# usage:
# import pdb, bdbtest
# pdb.runcall(bdbtest.test)
#
# then, in the debugger, type "b 13":

def test():
	a=0
	a=1
	a=2
	a=3
	a=4
	a=5
	a=6
	a=7
	a=8
	a=9

# the breakpoint will be at "a=4"
# now try to continue with "c", and you
# will see it still single stepping.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-27 19:11

Message:
Logged In: YES 
user_id=6380

Can you be more specific in your example?
I don't understand how I start a 10-line
program with runcall, since runcall requires
a function.
I also want to know exactly which syntax
you use to set the breakpoint.

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-26 10:58

Message:
Logged In: YES 
user_id=105700

Ok, I didn't check ti in, but I disagree to close it!
Do you think I would supply a patch if there weren't a problem?

The problem was reported to me by an IronPort Python
user who simply had the problem that pdb.runcall
on a given function *does not* run, but always single steps.
Your test doesn't get at the problem, since you don't set a
breakpoint, which is necessary to make it show up!

Here we go:
- write a simple program with some 10 lines
- start it with runcall
- set a breakpoint
- continue

and it will definately step!

With my patch, it works as expected.
Furthermore, Mark's F5 command is documented to
"start the program in the debugger". It never did so.
With the patch, it does.
Let's bring it to the end it deserves.

regards - chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-25 13:56

Message:
Logged In: YES 
user_id=6380

OK, closing.  Christian: please *don't* check it it!

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-05-25 06:17

Message:
Logged In: YES 
user_id=14198

This appears to have been fixed magically in Python 2.2. 
Using Python 2.1 with the sample demonstrates the bug, while
2.2 and current CVS both work correctly.  Haven't tried 2.1.1

A scan of the pdb and bdb logs don't show an obvious
candidate that fixed the bug, but to be quite honest, I
don't care *how* it was fixed now that it is <wink>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 21:36

Message:
Logged In: YES 
user_id=6380

You know, I cannot reproduce the problem!

I created this module:

import pdb
def foo():
    x = 12
    y = 2
    z = x**y
    print z
    return
pdb.set_trace()
print 12
print "hello world"
foo()

When I run it I get the pdb prompt.
When I hit "continue" at the prompt,
the whole program executes.

Before we start messing with this
I'd like to be able to reproduce
the problem so I can confirm that
it goes away!

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-23 22:55

Message:
Logged In: YES 
user_id=105700

There appears to be a simple solution.
I'm not used to pdb very much, so I cannot fur sure
say that my patch doesn't affect any extension of it,
but it seems to work just fine.

Idea: Allow botframe not to be a frame at all, but also None.
This makes it possible to use f_back in line 67:
            self.botframe = frame.f_back ##!!CT
In stop_here, we just omit the first two lines:
    def stop_here(self, frame):
        ##!!CT if self.stopframe is None:
        ##!!CT     return 1
        if frame is self.stopframe:
            return 1
        while frame is not None and frame is not self.stopframe:
            if frame is self.botframe:
                return 1
            frame = frame.f_back
        return 0

By this trick, botframe is llowed to be one level "on top"
of the
topmost frame, and we see the topmost frame behave as nicely
as every other.

-- chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 23:55

Message:
Logged In: YES 
user_id=6380

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:30

Message:
Logged In: YES 
user_id=31392

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 16:19

Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 16:18

Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470



From noreply@sourceforge.net  Tue May 28 01:53:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 May 2002 17:53:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
Message-ID: <E17CVEg-0000F5-00@usw-sf-web1.sourceforge.net>

Bugs item #210682, was opened at 2000-07-31 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470

Category: Python Library
>Group: Python 2.3
>Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Christian Tismer (tismer)
Summary: pdb can only step when at botframe (PR#4)

Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-27 20:53

Message:
Logged In: YES 
user_id=6380

OK, you convinced me.  Do you want to check it in or should
I do it?  If you want to do it, go ahead, and mark it as a
2.1 and 2.2 bugfix candidate.

And thanks for this solution!  (I tried this in IDLE, and
there's a benign effect there, too. :-)


----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-27 19:44

Message:
Logged In: YES 
user_id=105700

# test program for bdb buglet.
# usage:
# import pdb, bdbtest
# pdb.runcall(bdbtest.test)
#
# then, in the debugger, type "b 13":

def test():
	a=0
	a=1
	a=2
	a=3
	a=4
	a=5
	a=6
	a=7
	a=8
	a=9

# the breakpoint will be at "a=4"
# now try to continue with "c", and you
# will see it still single stepping.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-27 13:11

Message:
Logged In: YES 
user_id=6380

Can you be more specific in your example?
I don't understand how I start a 10-line
program with runcall, since runcall requires
a function.
I also want to know exactly which syntax
you use to set the breakpoint.

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-26 04:58

Message:
Logged In: YES 
user_id=105700

Ok, I didn't check ti in, but I disagree to close it!
Do you think I would supply a patch if there weren't a problem?

The problem was reported to me by an IronPort Python
user who simply had the problem that pdb.runcall
on a given function *does not* run, but always single steps.
Your test doesn't get at the problem, since you don't set a
breakpoint, which is necessary to make it show up!

Here we go:
- write a simple program with some 10 lines
- start it with runcall
- set a breakpoint
- continue

and it will definately step!

With my patch, it works as expected.
Furthermore, Mark's F5 command is documented to
"start the program in the debugger". It never did so.
With the patch, it does.
Let's bring it to the end it deserves.

regards - chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-25 07:56

Message:
Logged In: YES 
user_id=6380

OK, closing.  Christian: please *don't* check it it!

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-05-25 00:17

Message:
Logged In: YES 
user_id=14198

This appears to have been fixed magically in Python 2.2. 
Using Python 2.1 with the sample demonstrates the bug, while
2.2 and current CVS both work correctly.  Haven't tried 2.1.1

A scan of the pdb and bdb logs don't show an obvious
candidate that fixed the bug, but to be quite honest, I
don't care *how* it was fixed now that it is <wink>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 15:36

Message:
Logged In: YES 
user_id=6380

You know, I cannot reproduce the problem!

I created this module:

import pdb
def foo():
    x = 12
    y = 2
    z = x**y
    print z
    return
pdb.set_trace()
print 12
print "hello world"
foo()

When I run it I get the pdb prompt.
When I hit "continue" at the prompt,
the whole program executes.

Before we start messing with this
I'd like to be able to reproduce
the problem so I can confirm that
it goes away!

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-23 16:55

Message:
Logged In: YES 
user_id=105700

There appears to be a simple solution.
I'm not used to pdb very much, so I cannot fur sure
say that my patch doesn't affect any extension of it,
but it seems to work just fine.

Idea: Allow botframe not to be a frame at all, but also None.
This makes it possible to use f_back in line 67:
            self.botframe = frame.f_back ##!!CT
In stop_here, we just omit the first two lines:
    def stop_here(self, frame):
        ##!!CT if self.stopframe is None:
        ##!!CT     return 1
        if frame is self.stopframe:
            return 1
        while frame is not None and frame is not self.stopframe:
            if frame is self.botframe:
                return 1
            frame = frame.f_back
        return 0

By this trick, botframe is llowed to be one level "on top"
of the
topmost frame, and we see the topmost frame behave as nicely
as every other.

-- chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:55

Message:
Logged In: YES 
user_id=6380

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:30

Message:
Logged In: YES 
user_id=31392

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:19

Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:18

Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470



From noreply@sourceforge.net  Tue May 28 03:05:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 May 2002 19:05:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-561326 ] ihooks.FancyModuleLoader fails
Message-ID: <E17CWML-0002L9-00@usw-sf-web2.sourceforge.net>

Bugs item #561326, was opened at 2002-05-28 12:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561326&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Jack Jansen (jackjansen)
Summary: ihooks.FancyModuleLoader fails

Initial Comment:
ihooks.FancyModuleLoader() fails to load .py files on
Windows.  It yields a syntax error.

The root of the problem is that FancyModuleLoader()
uses imp.get_suffixes() to determine what mode to use
with a specific file extension.  Since the Universal
Newline support, .py files are specified as "rb"
(whereas previously they were "r"). 
FancyModuleImporter then opens the file using "rb", and
the "\r\n" line endings cause a syntax error.

To reproduce, simply execute Lib/rexec.py.  This will
create an interactive prompt in a restricted
environment. Attempt to import *any* module implemented
in a .py file not already loaded (eg, base64).  The
import fails with a SyntaxError

Assigning to Jack in the hope the correct fix is
obvious ;)  Assign back if you like!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561326&group_id=5470



From noreply@sourceforge.net  Tue May 28 12:01:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 May 2002 04:01:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-561326 ] ihooks.FancyModuleLoader fails
Message-ID: <E17Cej2-00070O-00@usw-sf-web1.sourceforge.net>

Bugs item #561326, was opened at 2002-05-28 04:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561326&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Jack Jansen (jackjansen)
Summary: ihooks.FancyModuleLoader fails

Initial Comment:
ihooks.FancyModuleLoader() fails to load .py files on
Windows.  It yields a syntax error.

The root of the problem is that FancyModuleLoader()
uses imp.get_suffixes() to determine what mode to use
with a specific file extension.  Since the Universal
Newline support, .py files are specified as "rb"
(whereas previously they were "r"). 
FancyModuleImporter then opens the file using "rb", and
the "\r\n" line endings cause a syntax error.

To reproduce, simply execute Lib/rexec.py.  This will
create an interactive prompt in a restricted
environment. Attempt to import *any* module implemented
in a .py file not already loaded (eg, base64).  The
import fails with a SyntaxError

Assigning to Jack in the hope the correct fix is
obvious ;)  Assign back if you like!

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-05-28 13:01

Message:
Logged In: YES 
user_id=45365

Turns out the mode flag in filedescr entries is not only passed to fopen() but also returned to Python scripts (through the imp interface), but in Python code we need "U" as the mode. Fixed in import.c rev. 2.202 by putting "U" in the filedescr table, and fixing it before passing it to fopen().

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561326&group_id=5470



From noreply@sourceforge.net  Wed May 29 02:33:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 May 2002 18:33:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
Message-ID: <E17CsL3-0000qh-00@usw-sf-web4.sourceforge.net>

Bugs item #210682, was opened at 2000-07-31 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Christian Tismer (tismer)
Summary: pdb can only step when at botframe (PR#4)

Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-28 21:33

Message:
Logged In: YES 
user_id=33168

Checked in as bdb.py 1.38/1.39 for current (fixed whitespace), 
1.33.6.2 for 2.2
1.31.2.1 for 2.1

Hopefully I got it right.  Closing.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-27 20:53

Message:
Logged In: YES 
user_id=6380

OK, you convinced me.  Do you want to check it in or should
I do it?  If you want to do it, go ahead, and mark it as a
2.1 and 2.2 bugfix candidate.

And thanks for this solution!  (I tried this in IDLE, and
there's a benign effect there, too. :-)


----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-27 19:44

Message:
Logged In: YES 
user_id=105700

# test program for bdb buglet.
# usage:
# import pdb, bdbtest
# pdb.runcall(bdbtest.test)
#
# then, in the debugger, type "b 13":

def test():
	a=0
	a=1
	a=2
	a=3
	a=4
	a=5
	a=6
	a=7
	a=8
	a=9

# the breakpoint will be at "a=4"
# now try to continue with "c", and you
# will see it still single stepping.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-27 13:11

Message:
Logged In: YES 
user_id=6380

Can you be more specific in your example?
I don't understand how I start a 10-line
program with runcall, since runcall requires
a function.
I also want to know exactly which syntax
you use to set the breakpoint.

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-26 04:58

Message:
Logged In: YES 
user_id=105700

Ok, I didn't check ti in, but I disagree to close it!
Do you think I would supply a patch if there weren't a problem?

The problem was reported to me by an IronPort Python
user who simply had the problem that pdb.runcall
on a given function *does not* run, but always single steps.
Your test doesn't get at the problem, since you don't set a
breakpoint, which is necessary to make it show up!

Here we go:
- write a simple program with some 10 lines
- start it with runcall
- set a breakpoint
- continue

and it will definately step!

With my patch, it works as expected.
Furthermore, Mark's F5 command is documented to
"start the program in the debugger". It never did so.
With the patch, it does.
Let's bring it to the end it deserves.

regards - chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-25 07:56

Message:
Logged In: YES 
user_id=6380

OK, closing.  Christian: please *don't* check it it!

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-05-25 00:17

Message:
Logged In: YES 
user_id=14198

This appears to have been fixed magically in Python 2.2. 
Using Python 2.1 with the sample demonstrates the bug, while
2.2 and current CVS both work correctly.  Haven't tried 2.1.1

A scan of the pdb and bdb logs don't show an obvious
candidate that fixed the bug, but to be quite honest, I
don't care *how* it was fixed now that it is <wink>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 15:36

Message:
Logged In: YES 
user_id=6380

You know, I cannot reproduce the problem!

I created this module:

import pdb
def foo():
    x = 12
    y = 2
    z = x**y
    print z
    return
pdb.set_trace()
print 12
print "hello world"
foo()

When I run it I get the pdb prompt.
When I hit "continue" at the prompt,
the whole program executes.

Before we start messing with this
I'd like to be able to reproduce
the problem so I can confirm that
it goes away!

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-05-23 16:55

Message:
Logged In: YES 
user_id=105700

There appears to be a simple solution.
I'm not used to pdb very much, so I cannot fur sure
say that my patch doesn't affect any extension of it,
but it seems to work just fine.

Idea: Allow botframe not to be a frame at all, but also None.
This makes it possible to use f_back in line 67:
            self.botframe = frame.f_back ##!!CT
In stop_here, we just omit the first two lines:
    def stop_here(self, frame):
        ##!!CT if self.stopframe is None:
        ##!!CT     return 1
        if frame is self.stopframe:
            return 1
        while frame is not None and frame is not self.stopframe:
            if frame is self.botframe:
                return 1
            frame = frame.f_back
        return 0

By this trick, botframe is llowed to be one level "on top"
of the
topmost frame, and we see the topmost frame behave as nicely
as every other.

-- chris

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:55

Message:
Logged In: YES 
user_id=6380

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:30

Message:
Logged In: YES 
user_id=31392

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:19

Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:18

Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470



From noreply@sourceforge.net  Wed May 29 03:10:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 May 2002 19:10:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-561770 ] re module MatchObject.group() problems
Message-ID: <E17Csv0-0002Zp-00@usw-sf-web3.sourceforge.net>

Bugs item #561770, was opened at 2002-05-28 22:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561770&group_id=5470

Category: Extension Modules
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Lavoie (christianlavoie)
Assigned to: Nobody/Anonymous (nobody)
Summary: re module MatchObject.group() problems

Initial Comment:
Test case:  
  
 #!/usr/bin/env python2.2  
  
import re  
  
test = re.compile('^([\w]*)(?:[\s]*)([\w]*)(?:, ([\w]*))*$')  
  
print test.match('deny ssh, https, x11, ldap,  
albert').groups()  
print test.match('deny ssh').groups()  
  
------  
  
Output of the test case:  
  
('deny', 'ssh', 'albert')  
('deny', 'ssh', None)  
  
----  
  
It is my opinion and the opinion of my Perl savvy friend  
that this is just plain wrong.  
  
We both think the output should have been:  
  
('deny', 'ssh')  
('deny', 'ssh', 'https', x11', 'ldap', 'albert')  
  
-----  
  
(Don't worry about the albert protocol)  
  
That is, that parenthesis grouping should be numbered  
by the order they appear in the matched target string, 
instead of by the order they appear in the  
regular expression. 
 
Have fun, 
Chris 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561770&group_id=5470



From noreply@sourceforge.net  Wed May 29 04:33:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 May 2002 20:33:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-561796 ] string.find causes lazy error
Message-ID: <E17CuDn-0000hB-00@usw-sf-web2.sourceforge.net>

Bugs item #561796, was opened at 2002-05-28 20:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561796&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Jones (morngnstar)
Assigned to: Nobody/Anonymous (nobody)
Summary: string.find causes lazy error

Initial Comment:
To repro:

1. start an interactive session (don't use IDLE, use the 
command line interface)
2. import string
3. string.split(u'test\0630', 'fail')
[u'test\0630']
4. string.find('test\xCC', u'test')
expect 0
actual -1

  Possibly my expectation is incorrect. Technically, 
since the default encoding is ASCII, and the code value 
0xCC has no meaning in ASCII, this code point can't be 
translated to Unicode. It would be unwarranted to 
assume that the correct translation was the same code 
value. So in general, the find cannot determine the result.

  However, it seems the proper behavior would then be to 
throw an exception. It cannot be determined that u'test' 
is in the string, but it also cannot be determined that it 
is not. So it is not correct to return -1 indicating the 
latter.

  Also, continue entering commands:

5. string.split(u'test\0630', 'fail')
expect [u'test\0630']
actual UnicodeError: ASCII decoding error: ordinal not in 
range(128)

  Note (5) is the same as (3) and is a command that 
should not depend on state, but the results are different. 
What is happening is that (4) actually generates the 
UnicodeError, but the exception-throwing mechanism is 
not invoked and interpretation continues. When (5) is 
executed, the error status is still set. It is checked, and 
the exception is now thrown.

  I have explored the code that causes this bug deeply 
and am working on a fix.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561796&group_id=5470



From noreply@sourceforge.net  Wed May 29 08:01:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 00:01:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-561822 ] ConfigParser has_option case sensitive
Message-ID: <E17CxSm-0002rE-00@usw-sf-web2.sourceforge.net>

Bugs item #561822, was opened at 2002-05-29 07:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561822&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Taylor (knet)
Assigned to: Nobody/Anonymous (nobody)
Summary: ConfigParser has_option case sensitive

Initial Comment:
In python 2.x ConfigParser.py has_option has the
following case-sensitive code:

	if not section or section == "DEFAULT":
		return self.__defaults.has_key(option)

whereas the rest of the module uses option.lower(). 
This means the DEFAULT section is case-sensitive but
other sections are not.

Attached is a patch to fix the problem in Python 2.2.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561822&group_id=5470



From noreply@sourceforge.net  Wed May 29 08:09:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 00:09:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-561825 ] Confusing error for "del f()"
Message-ID: <E17CxZz-0002xK-00@usw-sf-web2.sourceforge.net>

Bugs item #561825, was opened at 2002-05-29 17:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561825&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: Confusing error for "del f()"

Initial Comment:
>>> del f()
SyntaxError: can't assign to function call

I think this should be something more like:

SyntaxError: can't delete function call

I'm using Python 2.2.1 on Windows.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561825&group_id=5470



From noreply@sourceforge.net  Wed May 29 11:12:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 03:12:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17D0Rs-0003gl-00@usw-sf-web1.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 12:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jerome Alet (jalet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Wed May 29 11:14:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 03:14:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17D0TR-0003hy-00@usw-sf-web1.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 12:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jerome Alet (jalet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

----------------------------------------------------------------------

>Comment By: Jerome Alet (jalet)
Date: 2002-05-29 12:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Wed May 29 11:27:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 03:27:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-558153 ] Compile error _sre.c on Cray T3E
Message-ID: <E17D0g5-0007mZ-00@usw-sf-web3.sourceforge.net>

Bugs item #558153, was opened at 2002-05-20 03:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558153&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hadfield (hadfield)
>Assigned to: Fredrik Lundh (effbot)
Summary: Compile error _sre.c on Cray T3E

Initial Comment:
Building version 2.2.1 on a Cray T3E, compilation fails
on  _sre.c because it the name of a function (join)
clashes with a declaration in a system header
(unistd.h). Operating system is UNICOS/mk--sorry I
can't find out OS version number right now.

Solution is to rename the join function in _sre.c.
Patch is attached.

See thread entitled "Building Python on Cray T3E", 9-18
May 2002, on comp.lang.python.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-05-29 10:27

Message:
Logged In: YES 
user_id=6656

/F: Any objections?

----------------------------------------------------------------------

Comment By: Mark Hadfield (hadfield)
Date: 2002-05-20 03:17

Message:
Logged In: YES 
user_id=227147

Attempts to attach patch failed. Here it is:

*** /home/skip/tmp/_sre.c.~2.79~        Thu May  9 23:50:23 2002
--- /home/skip/tmp/_sre.c       Thu May  9 23:50:23 2002
***************
*** 1788,1794 ****
  #endif
  
  static PyObject*
! join(PyObject* list, PyObject* pattern)
  {
      /* join list elements */
  
--- 1788,1794 ----
  #endif
  
  static PyObject*
! join_list(PyObject* list, PyObject* pattern)
  {
      /* join list elements */
  
***************
*** 2241,2247 ****
      Py_DECREF(filter);
  
      /* convert list to single string (also removes list) */
!     item = join(list, self->pattern);
  
      if (!item)
          return NULL;
--- 2241,2247 ----
      Py_DECREF(filter);
  
      /* convert list to single string (also removes list) */
!     item = join_list(list, self->pattern);
  
      if (!item)
          return NULL;



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558153&group_id=5470



From noreply@sourceforge.net  Wed May 29 11:33:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 03:33:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-558914 ] Build md5.c fails on Cray T3E
Message-ID: <E17D0lM-0007qn-00@usw-sf-web3.sourceforge.net>

Bugs item #558914, was opened at 2002-05-21 23:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558914&group_id=5470

Category: Extension Modules
Group: Platform-specific
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Mark Hadfield (hadfield)
>Assigned to: Michael Hudson (mwh)
Summary: Build md5.c fails on Cray T3E

Initial Comment:
Building Python 2.2.1 on Cray T3E, compilation of md5.c
and md5module.c fails because UINT4 is undefined. The 
T3E does have an unsigned, 4-byte integer data type
(namely short) but the following code in Modules/md5.h
fails to find it:

/* UINT4 defines a four byte word */
#if SIZEOF_LONG == 4
typedef unsigned long int UINT4;
#else
#if INT_MAX == 2147483647
typedef unsigned int UINT4;
#endif
/* Too bad if neither is; pyport.h would need to be
fixed. */
#endif

So I changed it to:

/* UINT4 defines a four byte word */
#if SIZEOF_LONG == 4
typedef unsigned long int UINT4;
#elif SIZEOF_SHORT == 4
typedef unsigned short int UINT4;
#elif INT_MAX == 2147483647
typedef unsigned int UINT4;
#endif
/* Too bad if neither is; pyport.h would need to be
fixed. */

Also, Modules/md5.h defines a UINT2. This is a worry
because T3E's don't have a 2-byte integer data type. It
turns out that this symbol is never used.

With modified Modules/md5.h (attached), the md5 module
compiles OK and passes tests.



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-05-29 10:33

Message:
Logged In: YES 
user_id=6656

Checked in as Modules/md5.h revision 2.8.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=558914&group_id=5470



From noreply@sourceforge.net  Wed May 29 11:33:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 03:33:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-561796 ] string.find causes lazy error
Message-ID: <E17D0m0-0006Sw-00@usw-sf-web4.sourceforge.net>

Bugs item #561796, was opened at 2002-05-29 03:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561796&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Jones (morngnstar)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: string.find causes lazy error

Initial Comment:
To repro:

1. start an interactive session (don't use IDLE, use the 
command line interface)
2. import string
3. string.split(u'test\0630', 'fail')
[u'test\0630']
4. string.find('test\xCC', u'test')
expect 0
actual -1

  Possibly my expectation is incorrect. Technically, 
since the default encoding is ASCII, and the code value 
0xCC has no meaning in ASCII, this code point can't be 
translated to Unicode. It would be unwarranted to 
assume that the correct translation was the same code 
value. So in general, the find cannot determine the result.

  However, it seems the proper behavior would then be to 
throw an exception. It cannot be determined that u'test' 
is in the string, but it also cannot be determined that it 
is not. So it is not correct to return -1 indicating the 
latter.

  Also, continue entering commands:

5. string.split(u'test\0630', 'fail')
expect [u'test\0630']
actual UnicodeError: ASCII decoding error: ordinal not in 
range(128)

  Note (5) is the same as (3) and is a command that 
should not depend on state, but the results are different. 
What is happening is that (4) actually generates the 
UnicodeError, but the exception-throwing mechanism is 
not invoked and interpretation continues. When (5) is 
executed, the error status is still set. It is checked, and 
the exception is now thrown.

  I have explored the code that causes this bug deeply 
and am working on a fix.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-05-29 10:33

Message:
Logged In: YES 
user_id=38388

I can't reproduce 3./5. in the latest CVS version, but I
do get strange output from running:

>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1

Looks like an exception is set but not properly
propogated back the caller.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561796&group_id=5470



From noreply@sourceforge.net  Wed May 29 11:36:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 03:36:27 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-547537 ] cStringIO should provide a binary option
Message-ID: <E17D0od-0006Ur-00@usw-sf-web4.sourceforge.net>

Feature Requests item #547537, was opened at 2002-04-23 12:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=547537&group_id=5470

>Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Nobody/Anonymous (nobody)
>Summary: cStringIO should provide a binary option

Initial Comment:
The last few comments added to bug 216388 indicate a
new problem in cStringIO. Rather than abusing that bug
report, I'm opening a new one here. The problem is that
cStringIO now accepts Unicode strings to write(), but
when you use this, getvalue() returns binary garbage.
The cause is apparently MAL's checkin for cStringIO
2.30, which enabled read buffers.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-05-29 10:36

Message:
Logged In: YES 
user_id=38388

Guido already fixed this in CVS, so I'll turn 
the bug into a feature request:

cStringIO should provide a way to "open" a
file in binary mode.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 00:02

Message:
Logged In: YES 
user_id=6380

I think that adding a binary mode to cStringIO is okay, but
the default should be text, and until we have the binary
mode option, the format should be t#.

Another solution would be to let cStringIO act more like
StringIO; after all that was its original intention. But
since that would require a major overhaul, I'm not seriously
proposing that.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-27 15:13

Message:
Logged In: YES 
user_id=38388

Another note: the bug title is wrong: cStringIO doesn't
mangle Unicode, it just returns the raw binary data. Not
that this is of much use, but it's in sync with what the
file object does.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-27 15:02

Message:
Logged In: YES 
user_id=38388

The idea to rip out the old string only approach was to make
cStringIO more compatible to the file object implementation.

Rather than switching from s# to t#, the cStringIO object
should maintain a binary switch just like the file
object does and then use s# for pseudo files opened
in binary mode (default) and t# for text mode ones.

Note that in any case, Unicode should be explicitly
encoded before writing it to a file. 

Simply switching to t# would cause compatibility 
problems, since a different buffer API would be used
for all input objects.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-26 21:08

Message:
Logged In: YES 
user_id=6380

Should I just check this in? It looks pretty safe to me...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-23 12:59

Message:
Logged In: YES 
user_id=6380

I wonder if perhaps the fix is as simple as using "t#"
instead of "s#" in the PyArg_... format string in P_write().
That accepts Unicode strings as args to write() only when
they are ASCII (actually, it uses the default encoding).

Marc-Andre, can you explain the reason for the change in the
first place (other than fixing a dubious dependency on
PyString_GetSize() raising an exception for a non-string
object)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=547537&group_id=5470



From noreply@sourceforge.net  Wed May 29 11:38:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 03:38:21 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-547537 ] cStringIO should provide a binary option
Message-ID: <E17D0qT-0007u8-00@usw-sf-web3.sourceforge.net>

Feature Requests item #547537, was opened at 2002-04-23 12:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=547537&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: cStringIO should provide a binary option

Initial Comment:
The last few comments added to bug 216388 indicate a
new problem in cStringIO. Rather than abusing that bug
report, I'm opening a new one here. The problem is that
cStringIO now accepts Unicode strings to write(), but
when you use this, getvalue() returns binary garbage.
The cause is apparently MAL's checkin for cStringIO
2.30, which enabled read buffers.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-05-29 10:36

Message:
Logged In: YES 
user_id=38388

Guido already fixed this in CVS, so I'll turn 
the bug into a feature request:

cStringIO should provide a way to "open" a
file in binary mode.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 00:02

Message:
Logged In: YES 
user_id=6380

I think that adding a binary mode to cStringIO is okay, but
the default should be text, and until we have the binary
mode option, the format should be t#.

Another solution would be to let cStringIO act more like
StringIO; after all that was its original intention. But
since that would require a major overhaul, I'm not seriously
proposing that.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-27 15:13

Message:
Logged In: YES 
user_id=38388

Another note: the bug title is wrong: cStringIO doesn't
mangle Unicode, it just returns the raw binary data. Not
that this is of much use, but it's in sync with what the
file object does.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-27 15:02

Message:
Logged In: YES 
user_id=38388

The idea to rip out the old string only approach was to make
cStringIO more compatible to the file object implementation.

Rather than switching from s# to t#, the cStringIO object
should maintain a binary switch just like the file
object does and then use s# for pseudo files opened
in binary mode (default) and t# for text mode ones.

Note that in any case, Unicode should be explicitly
encoded before writing it to a file. 

Simply switching to t# would cause compatibility 
problems, since a different buffer API would be used
for all input objects.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-26 21:08

Message:
Logged In: YES 
user_id=6380

Should I just check this in? It looks pretty safe to me...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-23 12:59

Message:
Logged In: YES 
user_id=6380

I wonder if perhaps the fix is as simple as using "t#"
instead of "s#" in the PyArg_... format string in P_write().
That accepts Unicode strings as args to write() only when
they are ASCII (actually, it uses the default encoding).

Marc-Andre, can you explain the reason for the change in the
first place (other than fixing a dubious dependency on
PyString_GetSize() raising an exception for a non-string
object)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=547537&group_id=5470



From noreply@sourceforge.net  Wed May 29 12:33:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 04:33:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-561796 ] string.find causes lazy error
Message-ID: <E17D1i2-00062F-00@usw-sf-web2.sourceforge.net>

Bugs item #561796, was opened at 2002-05-29 03:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561796&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Greg Jones (morngnstar)
Assigned to: M.-A. Lemburg (lemburg)
Summary: string.find causes lazy error

Initial Comment:
To repro:

1. start an interactive session (don't use IDLE, use the 
command line interface)
2. import string
3. string.split(u'test\0630', 'fail')
[u'test\0630']
4. string.find('test\xCC', u'test')
expect 0
actual -1

  Possibly my expectation is incorrect. Technically, 
since the default encoding is ASCII, and the code value 
0xCC has no meaning in ASCII, this code point can't be 
translated to Unicode. It would be unwarranted to 
assume that the correct translation was the same code 
value. So in general, the find cannot determine the result.

  However, it seems the proper behavior would then be to 
throw an exception. It cannot be determined that u'test' 
is in the string, but it also cannot be determined that it 
is not. So it is not correct to return -1 indicating the 
latter.

  Also, continue entering commands:

5. string.split(u'test\0630', 'fail')
expect [u'test\0630']
actual UnicodeError: ASCII decoding error: ordinal not in 
range(128)

  Note (5) is the same as (3) and is a command that 
should not depend on state, but the results are different. 
What is happening is that (4) actually generates the 
UnicodeError, but the exception-throwing mechanism is 
not invoked and interpretation continues. When (5) is 
executed, the error status is still set. It is checked, and 
the exception is now thrown.

  I have explored the code that causes this bug deeply 
and am working on a fix.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-05-29 11:33

Message:
Logged In: YES 
user_id=38388

Just checked in a fix in CVS.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-05-29 10:33

Message:
Logged In: YES 
user_id=38388

I can't reproduce 3./5. in the latest CVS version, but I
do get strange output from running:

>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1

Looks like an exception is set but not properly
propogated back the caller.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561796&group_id=5470



From noreply@sourceforge.net  Wed May 29 12:33:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 04:33:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-561796 ] string.find causes lazy error
Message-ID: <E17D1iI-0007Eh-00@usw-sf-web4.sourceforge.net>

Bugs item #561796, was opened at 2002-05-29 03:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561796&group_id=5470

Category: Python Library
>Group: Python 2.2.1 candidate
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Greg Jones (morngnstar)
Assigned to: M.-A. Lemburg (lemburg)
Summary: string.find causes lazy error

Initial Comment:
To repro:

1. start an interactive session (don't use IDLE, use the 
command line interface)
2. import string
3. string.split(u'test\0630', 'fail')
[u'test\0630']
4. string.find('test\xCC', u'test')
expect 0
actual -1

  Possibly my expectation is incorrect. Technically, 
since the default encoding is ASCII, and the code value 
0xCC has no meaning in ASCII, this code point can't be 
translated to Unicode. It would be unwarranted to 
assume that the correct translation was the same code 
value. So in general, the find cannot determine the result.

  However, it seems the proper behavior would then be to 
throw an exception. It cannot be determined that u'test' 
is in the string, but it also cannot be determined that it 
is not. So it is not correct to return -1 indicating the 
latter.

  Also, continue entering commands:

5. string.split(u'test\0630', 'fail')
expect [u'test\0630']
actual UnicodeError: ASCII decoding error: ordinal not in 
range(128)

  Note (5) is the same as (3) and is a command that 
should not depend on state, but the results are different. 
What is happening is that (4) actually generates the 
UnicodeError, but the exception-throwing mechanism is 
not invoked and interpretation continues. When (5) is 
executed, the error status is still set. It is checked, and 
the exception is now thrown.

  I have explored the code that causes this bug deeply 
and am working on a fix.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-05-29 11:33

Message:
Logged In: YES 
user_id=38388

Just checked in a fix in CVS.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-05-29 10:33

Message:
Logged In: YES 
user_id=38388

I can't reproduce 3./5. in the latest CVS version, but I
do get strange output from running:

>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1

Looks like an exception is set but not properly
propogated back the caller.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561796&group_id=5470



From noreply@sourceforge.net  Wed May 29 13:05:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 05:05:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-561047 ] Maximum recursion limit exceeded
Message-ID: <E17D2Cb-0006JK-00@usw-sf-web2.sourceforge.net>

Bugs item #561047, was opened at 2002-05-27 14:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561047&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Gritsch (markus_gritsch)
Assigned to: Fredrik Lundh (effbot)
Summary: Maximum recursion limit exceeded

Initial Comment:
Hi!

I think I discovered a limitation of the "new" Regular
Expression engine.  I
have put together an example which shows the behavior at
 
http://stud4.tuwien.ac.at/~e9326522/temporary/re_bug_example.zip
(69kB)

When the script is run with Python 1.5.2 by invoking
  psmergeNS.py *.ps

everything is fine and it produces a merged output file
containing both
PostScript files.

When using Python 2.x the following Exception is raised:

  Traceback (most recent call last):
    File "psmergeNS4.py", line 35, in ?
      pages = theRE.findall(contents)
  RuntimeError: maximum recursion limit exceeded

This behavior is the same with the Linux and the Win32
version of Python.

Markus



----------------------------------------------------------------------

Comment By: Bastian Kleineidam (calvin)
Date: 2002-05-29 14:05

Message:
Logged In: YES 
user_id=9205

I had the same problem, but only when using *? matching
several kB text.
It seems the the *? backtracking function is recursive and
cannot handle several thousand characters...

Greetings

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561047&group_id=5470



From noreply@sourceforge.net  Wed May 29 13:42:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 05:42:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17D2mD-0007wb-00@usw-sf-web4.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 12:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jerome Alet (jalet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

----------------------------------------------------------------------

>Comment By: Jerome Alet (jalet)
Date: 2002-05-29 14:42

Message:
Logged In: YES 
user_id=97214

I've done more tests, the bug only occurs if every line has
a backslash at its end :

liste = [ \
            "item0", \
            "item1", \
            # ... many many lines
            "itemN" ]

and it works if I remove the \ from each end of line.

hth.

----------------------------------------------------------------------

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 12:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Wed May 29 15:36:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 07:36:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-561913 ] float values in lists
Message-ID: <E17D4ZE-0007Xp-00@usw-sf-web2.sourceforge.net>

Bugs item #561913, was opened at 2002-05-29 09:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561913&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Townley (thranil)
Assigned to: Nobody/Anonymous (nobody)
Summary: float values in lists

Initial Comment:
System: Windows 2000

Execute the following script to reproduce problem:
theList = [3.14,59,"A string", 1024] 
print theList 

What I am seeing:
The float value "3.14" is being displayed as 
3.1400000000000001. 



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561913&group_id=5470



From noreply@sourceforge.net  Wed May 29 15:39:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 07:39:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-561913 ] float values in lists
Message-ID: <E17D4bf-0000Fp-00@usw-sf-web4.sourceforge.net>

Bugs item #561913, was opened at 2002-05-29 14:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561913&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Brian Townley (thranil)
>Assigned to: Michael Hudson (mwh)
Summary: float values in lists

Initial Comment:
System: Windows 2000

Execute the following script to reproduce problem:
theList = [3.14,59,"A string", 1024] 
print theList 

What I am seeing:
The float value "3.14" is being displayed as 
3.1400000000000001. 



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-29 14:39

Message:
Logged In: YES 
user_id=6656

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for more information:

http://python.sourceforge.net/devel-docs/tut/node14.html

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561913&group_id=5470



From noreply@sourceforge.net  Wed May 29 15:41:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 07:41:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-561913 ] float values in lists
Message-ID: <E17D4dl-0000Gj-00@usw-sf-web4.sourceforge.net>

Bugs item #561913, was opened at 2002-05-29 14:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561913&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Brian Townley (thranil)
Assigned to: Michael Hudson (mwh)
Summary: float values in lists

Initial Comment:
System: Windows 2000

Execute the following script to reproduce problem:
theList = [3.14,59,"A string", 1024] 
print theList 

What I am seeing:
The float value "3.14" is being displayed as 
3.1400000000000001. 



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-05-29 14:41

Message:
Logged In: YES 
user_id=6656

Hmm, try this URL instead:

http://www.python.org/doc/2.2.1/tut/node14.html

(I've fixed the canned response).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-29 14:39

Message:
Logged In: YES 
user_id=6656

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for more information:

http://python.sourceforge.net/devel-docs/tut/node14.html

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561913&group_id=5470



From noreply@sourceforge.net  Wed May 29 15:56:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 07:56:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-561913 ] float values in lists
Message-ID: <E17D4sc-0005yn-00@usw-sf-web1.sourceforge.net>

Bugs item #561913, was opened at 2002-05-29 09:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561913&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Brian Townley (thranil)
Assigned to: Michael Hudson (mwh)
Summary: float values in lists

Initial Comment:
System: Windows 2000

Execute the following script to reproduce problem:
theList = [3.14,59,"A string", 1024] 
print theList 

What I am seeing:
The float value "3.14" is being displayed as 
3.1400000000000001. 



----------------------------------------------------------------------

>Comment By: Brian Townley (thranil)
Date: 2002-05-29 09:56

Message:
Logged In: YES 
user_id=555127

The explanation given makes sense, yet I am unable to 
reproduce this floating point rounding error with a Visual C++ 
compiled project. Can you recommend a way to repro it so I 
can see this issue within a compilable language?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-29 09:41

Message:
Logged In: YES 
user_id=6656

Hmm, try this URL instead:

http://www.python.org/doc/2.2.1/tut/node14.html

(I've fixed the canned response).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-29 09:39

Message:
Logged In: YES 
user_id=6656

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for more information:

http://python.sourceforge.net/devel-docs/tut/node14.html

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561913&group_id=5470



From noreply@sourceforge.net  Wed May 29 16:06:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 08:06:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-561913 ] float values in lists
Message-ID: <E17D51d-0001sk-00@usw-sf-web3.sourceforge.net>

Bugs item #561913, was opened at 2002-05-29 10:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561913&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Brian Townley (thranil)
Assigned to: Michael Hudson (mwh)
Summary: float values in lists

Initial Comment:
System: Windows 2000

Execute the following script to reproduce problem:
theList = [3.14,59,"A string", 1024] 
print theList 

What I am seeing:
The float value "3.14" is being displayed as 
3.1400000000000001. 



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-05-29 11:06

Message:
Logged In: YES 
user_id=31435

For example, in C/C++ print with format %.17g

----------------------------------------------------------------------

Comment By: Brian Townley (thranil)
Date: 2002-05-29 10:56

Message:
Logged In: YES 
user_id=555127

The explanation given makes sense, yet I am unable to 
reproduce this floating point rounding error with a Visual C++ 
compiled project. Can you recommend a way to repro it so I 
can see this issue within a compilable language?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-29 10:41

Message:
Logged In: YES 
user_id=6656

Hmm, try this URL instead:

http://www.python.org/doc/2.2.1/tut/node14.html

(I've fixed the canned response).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-05-29 10:39

Message:
Logged In: YES 
user_id=6656

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for more information:

http://python.sourceforge.net/devel-docs/tut/node14.html

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561913&group_id=5470



From noreply@sourceforge.net  Wed May 29 17:11:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 09:11:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-561770 ] re module MatchObject.group() problems
Message-ID: <E17D62u-00008g-00@usw-sf-web2.sourceforge.net>

Bugs item #561770, was opened at 2002-05-28 21:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561770&group_id=5470

Category: Extension Modules
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Lavoie (christianlavoie)
>Assigned to: Fredrik Lundh (effbot)
Summary: re module MatchObject.group() problems

Initial Comment:
Test case:  
  
 #!/usr/bin/env python2.2  
  
import re  
  
test = re.compile('^([\w]*)(?:[\s]*)([\w]*)(?:, ([\w]*))*$')  
  
print test.match('deny ssh, https, x11, ldap,  
albert').groups()  
print test.match('deny ssh').groups()  
  
------  
  
Output of the test case:  
  
('deny', 'ssh', 'albert')  
('deny', 'ssh', None)  
  
----  
  
It is my opinion and the opinion of my Perl savvy friend  
that this is just plain wrong.  
  
We both think the output should have been:  
  
('deny', 'ssh')  
('deny', 'ssh', 'https', x11', 'ldap', 'albert')  
  
-----  
  
(Don't worry about the albert protocol)  
  
That is, that parenthesis grouping should be numbered  
by the order they appear in the matched target string, 
instead of by the order they appear in the  
regular expression. 
 
Have fun, 
Chris 

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-29 11:11

Message:
Logged In: YES 
user_id=80475

I think group numbering is correct as is because:
1.  The behavior matches the documentation
2.  It is useful so that the \1 \2 substitutions can be 
calculated before runtime
3.  From my brief perusal of Perl docs, this matches Perl 
behavior also
4.  Order of match doesn't make sense with hierarchial 
groupings where match may belong to both an inner and 
outer group.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561770&group_id=5470



From noreply@sourceforge.net  Wed May 29 18:07:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 10:07:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-561796 ] string.find causes lazy error
Message-ID: <E17D6vO-0000h2-00@usw-sf-web2.sourceforge.net>

Bugs item #561796, was opened at 2002-05-28 20:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561796&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Greg Jones (morngnstar)
Assigned to: M.-A. Lemburg (lemburg)
Summary: string.find causes lazy error

Initial Comment:
To repro:

1. start an interactive session (don't use IDLE, use the 
command line interface)
2. import string
3. string.split(u'test\0630', 'fail')
[u'test\0630']
4. string.find('test\xCC', u'test')
expect 0
actual -1

  Possibly my expectation is incorrect. Technically, 
since the default encoding is ASCII, and the code value 
0xCC has no meaning in ASCII, this code point can't be 
translated to Unicode. It would be unwarranted to 
assume that the correct translation was the same code 
value. So in general, the find cannot determine the result.

  However, it seems the proper behavior would then be to 
throw an exception. It cannot be determined that u'test' 
is in the string, but it also cannot be determined that it 
is not. So it is not correct to return -1 indicating the 
latter.

  Also, continue entering commands:

5. string.split(u'test\0630', 'fail')
expect [u'test\0630']
actual UnicodeError: ASCII decoding error: ordinal not in 
range(128)

  Note (5) is the same as (3) and is a command that 
should not depend on state, but the results are different. 
What is happening is that (4) actually generates the 
UnicodeError, but the exception-throwing mechanism is 
not invoked and interpretation continues. When (5) is 
executed, the error status is still set. It is checked, and 
the exception is now thrown.

  I have explored the code that causes this bug deeply 
and am working on a fix.

----------------------------------------------------------------------

>Comment By: Greg Jones (morngnstar)
Date: 2002-05-29 10:07

Message:
Logged In: YES 
user_id=554883

  Oops, the original repro step for split should have been:

string.split(u'test\u0630', 'fail')

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-05-29 04:33

Message:
Logged In: YES 
user_id=38388

Just checked in a fix in CVS.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-05-29 03:33

Message:
Logged In: YES 
user_id=38388

I can't reproduce 3./5. in the latest CVS version, but I
do get strange output from running:

>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1

Looks like an exception is set but not properly
propogated back the caller.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561796&group_id=5470



From noreply@sourceforge.net  Wed May 29 18:48:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 10:48:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-561998 ] Library -- types module -- StringTypes
Message-ID: <E17D7Z8-0007iE-00@usw-sf-web1.sourceforge.net>

Bugs item #561998, was opened at 2002-05-29 13:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561998&group_id=5470

Category: Documentation
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexis Layton (alayton)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Library -- types module -- StringTypes

Initial Comment:
MINOR

types.StringTypes is documented as a list when it is in fact a tuple in order to be compatible with isinstance. The documentation should be changed to say so.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561998&group_id=5470



From noreply@sourceforge.net  Wed May 29 19:06:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 11:06:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-561998 ] Library -- types module -- StringTypes
Message-ID: <E17D7qB-0003i8-00@usw-sf-web3.sourceforge.net>

Bugs item #561998, was opened at 2002-05-29 13:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561998&group_id=5470

Category: Documentation
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alexis Layton (alayton)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Library -- types module -- StringTypes

Initial Comment:
MINOR

types.StringTypes is documented as a list when it is in fact a tuple in order to be compatible with isinstance. The documentation should be changed to say so.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-29 14:06

Message:
Logged In: YES 
user_id=3066

Already fixed in the sources for the next releases.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561998&group_id=5470



From noreply@sourceforge.net  Wed May 29 19:32:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 11:32:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-561796 ] string.find causes lazy error
Message-ID: <E17D8Fb-0002bv-00@usw-sf-web4.sourceforge.net>

Bugs item #561796, was opened at 2002-05-29 03:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561796&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Greg Jones (morngnstar)
Assigned to: M.-A. Lemburg (lemburg)
Summary: string.find causes lazy error

Initial Comment:
To repro:

1. start an interactive session (don't use IDLE, use the 
command line interface)
2. import string
3. string.split(u'test\0630', 'fail')
[u'test\0630']
4. string.find('test\xCC', u'test')
expect 0
actual -1

  Possibly my expectation is incorrect. Technically, 
since the default encoding is ASCII, and the code value 
0xCC has no meaning in ASCII, this code point can't be 
translated to Unicode. It would be unwarranted to 
assume that the correct translation was the same code 
value. So in general, the find cannot determine the result.

  However, it seems the proper behavior would then be to 
throw an exception. It cannot be determined that u'test' 
is in the string, but it also cannot be determined that it 
is not. So it is not correct to return -1 indicating the 
latter.

  Also, continue entering commands:

5. string.split(u'test\0630', 'fail')
expect [u'test\0630']
actual UnicodeError: ASCII decoding error: ordinal not in 
range(128)

  Note (5) is the same as (3) and is a command that 
should not depend on state, but the results are different. 
What is happening is that (4) actually generates the 
UnicodeError, but the exception-throwing mechanism is 
not invoked and interpretation continues. When (5) is 
executed, the error status is still set. It is checked, and 
the exception is now thrown.

  I have explored the code that causes this bug deeply 
and am working on a fix.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-05-29 18:32

Message:
Logged In: YES 
user_id=38388

It still works for me:

>>> string.split(u'test\u0630', 'fail')
[u'test\u0630']
>>> string.split(u'test\u0630', 'fail')
[u'test\u0630']
>>> string.split(u'test\u0630', 'fail')
[u'test\u0630']
>>> string.split(u'test\u0630', 'fail')
[u'test\u0630']
>>> string.split(u'test\u0630', 'fail')
[u'test\u0630']
>>> string.split(u'test\u0630', 'fail')
[u'test\u0630']

I tried this with Python 2.1.3, 2.2 and CVS. I
think that the problem from the .find()
method just propogated into the next
method call and that's why you were seeing
strange results from .split()


----------------------------------------------------------------------

Comment By: Greg Jones (morngnstar)
Date: 2002-05-29 17:07

Message:
Logged In: YES 
user_id=554883

  Oops, the original repro step for split should have been:

string.split(u'test\u0630', 'fail')

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-05-29 11:33

Message:
Logged In: YES 
user_id=38388

Just checked in a fix in CVS.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-05-29 10:33

Message:
Logged In: YES 
user_id=38388

I can't reproduce 3./5. in the latest CVS version, but I
do get strange output from running:

>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1
>>> string.find('test\xCC', u'test')
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> string.find('test\xCC', u'test')
-1

Looks like an exception is set but not properly
propogated back the caller.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561796&group_id=5470



From noreply@sourceforge.net  Wed May 29 20:45:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 12:45:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-532467 ] 6.9 The raise statement is confusing
Message-ID: <E17D9OD-0003Or-00@usw-sf-web4.sourceforge.net>

Bugs item #532467, was opened at 2002-03-20 08:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 6
Submitted By: Patrick K. O'Brien (pobrien)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 6.9 The raise statement is confusing

Initial Comment:
The description supplied for "6.9 The raise statement" 
is confusing. In particular, it starts by explaining 
the intent of each "expresssion" and midway switches 
to "object" instead of expression. In particular, I 
can't make heads or tails out of the following passage:

"If the first object is a string, it then raises the 
exception identified by the first object, with the 
second one (or None) as its parameter. If the first 
object is a class or instance, it raises the exception 
identified by the class of the instance determined in 
the previous step, with the instance as its parameter."

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-29 15:45

Message:
Logged In: YES 
user_id=3066

Bumped priority since Raymond is waiting for my review.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 21:25

Message:
Logged In: YES 
user_id=80475

Thanks Patrick.

Since I'm the new guy, I'll defer additional changes to 
Fred.  My patch style is to make the least invasive change 
that improves clarity and accuracy.  

Also, this may be a case where additional wording, even if 
informative and accurate, may detract from a strong 
understanding of how raise works.  

This section's cyclomatic complexity (nested if/elif/else 
paths) already impinges its understandability.

----------------------------------------------------------------------

Comment By: Patrick K. O'Brien (pobrien)
Date: 2002-05-16 10:34

Message:
Logged In: YES 
user_id=179604

Raymond, I really appreciate your patches. The big patch is 
terrific and gets my vote. I do have one more request for 
clarification in what you wrote. You say:

"If the first expression is a class object, it raises the 
exception identified by the class of an instance determined 
by the second expression.  If the second expression is an 
instance, that instance is used."

So we're talking about the form: raise class, instance

What I'm picturing is a situation where the second 
expression is an instance of a class other than the class 
object used as the first expression. Is this allowed, 
disallowed, allowed but nonsensical or allowed because it 
offers some practical benefit that I'm just not grasping?

I found and read the essay on "Standard Exception Classes 
in Python 1.5" 
(http://www.python.org/doc/essays/stdexceptions.html) and I 
can see that much was done to maintain backward 
compatibility. and apparently the "raise class, instance" 
form goes back quite a ways. Is this just a wart to be 
avoided? I'm probably expecting too much to expect the 
language reference to distinguish between what is strictly 
allowed vs. why it is allowed and whether it should even be 
used at all. It's just that the more I dug into this the 
more confused I became. I think I'm understanding the 
situation now.

In any case, make of this what you will. The bottom line is 
that your batch is definitely an improvement and I greatly 
appreciate your time and effort on this. Thanks.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-16 00:10

Message:
Logged In: YES 
user_id=80475

Attached two alternative patches.

The first makes minimal changes to achieve a clear and 
consistent use of "objects" versus "expressions".

The second alternative re-paragraphs the text and uses 
parallel sentence contruction to provide (IMHO) 
greater clarity without getting a headache reading it.

If accepted, please re-assign to Raymond for a commit to 
2.3 and to release22-maint.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470



From noreply@sourceforge.net  Thu May 30 06:59:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 22:59:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-562188 ] test_signal.py fails on FreeBSD-4-stable
Message-ID: <E17DIyD-0001II-00@usw-sf-web3.sourceforge.net>

Bugs item #562188, was opened at 2002-05-30 05:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562188&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Till Plewe (llit)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_signal.py fails on FreeBSD-4-stable

Initial Comment:
./python ./Lib/test/test_signal.py
starting pause() loop...
call pause()...
+ sleep 2
+ kill -5 80290
handlerA (5, <frame object at 0x8157e0c>)
pause() returned
call pause()...
+ sleep 2
+ kill -2 80290
handlerB (2, <frame object at 0x8157e0c>)
HandlerBCalled exception caught
call pause()...
+ sleep 2
+ kill -3 80290
KeyboardInterrupt (assume the alarm() went off)
blocking SIGHUP
sending SIGHUP
Traceback (most recent call last):
  File "./Lib/test/test_signal.py", line 92, in ?
    raise TestFailed, "HUP not pending"
test_support.TestFailed: HUP not pending


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562188&group_id=5470



From noreply@sourceforge.net  Thu May 30 07:01:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 23:01:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-562188 ] test_signal.py fails on FreeBSD-4-stable
Message-ID: <E17DJ0H-0001Jl-00@usw-sf-web3.sourceforge.net>

Bugs item #562188, was opened at 2002-05-30 05:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562188&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 3
Submitted By: Till Plewe (llit)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_signal.py fails on FreeBSD-4-stable

Initial Comment:
./python ./Lib/test/test_signal.py
starting pause() loop...
call pause()...
+ sleep 2
+ kill -5 80290
handlerA (5, <frame object at 0x8157e0c>)
pause() returned
call pause()...
+ sleep 2
+ kill -2 80290
handlerB (2, <frame object at 0x8157e0c>)
HandlerBCalled exception caught
call pause()...
+ sleep 2
+ kill -3 80290
KeyboardInterrupt (assume the alarm() went off)
blocking SIGHUP
sending SIGHUP
Traceback (most recent call last):
  File "./Lib/test/test_signal.py", line 92, in ?
    raise TestFailed, "HUP not pending"
test_support.TestFailed: HUP not pending


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562188&group_id=5470



From noreply@sourceforge.net  Thu May 30 07:02:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 May 2002 23:02:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-562188 ] test_signal.py fails on FreeBSD-4-stable
Message-ID: <E17DJ1S-0001KY-00@usw-sf-web3.sourceforge.net>

Bugs item #562188, was opened at 2002-05-30 05:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562188&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 2
Submitted By: Till Plewe (llit)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_signal.py fails on FreeBSD-4-stable

Initial Comment:
./python ./Lib/test/test_signal.py
starting pause() loop...
call pause()...
+ sleep 2
+ kill -5 80290
handlerA (5, <frame object at 0x8157e0c>)
pause() returned
call pause()...
+ sleep 2
+ kill -2 80290
handlerB (2, <frame object at 0x8157e0c>)
HandlerBCalled exception caught
call pause()...
+ sleep 2
+ kill -3 80290
KeyboardInterrupt (assume the alarm() went off)
blocking SIGHUP
sending SIGHUP
Traceback (most recent call last):
  File "./Lib/test/test_signal.py", line 92, in ?
    raise TestFailed, "HUP not pending"
test_support.TestFailed: HUP not pending


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562188&group_id=5470



From noreply@sourceforge.net  Thu May 30 10:15:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 May 2002 02:15:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-562188 ] test_signal.py fails on FreeBSD-4-stable
Message-ID: <E17DM26-0003YW-00@usw-sf-web3.sourceforge.net>

Bugs item #562188, was opened at 2002-05-30 05:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562188&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 5
Submitted By: Till Plewe (llit)
>Assigned to: Michael Hudson (mwh)
Summary: test_signal.py fails on FreeBSD-4-stable

Initial Comment:
./python ./Lib/test/test_signal.py
starting pause() loop...
call pause()...
+ sleep 2
+ kill -5 80290
handlerA (5, <frame object at 0x8157e0c>)
pause() returned
call pause()...
+ sleep 2
+ kill -2 80290
handlerB (2, <frame object at 0x8157e0c>)
HandlerBCalled exception caught
call pause()...
+ sleep 2
+ kill -3 80290
KeyboardInterrupt (assume the alarm() went off)
blocking SIGHUP
sending SIGHUP
Traceback (most recent call last):
  File "./Lib/test/test_signal.py", line 92, in ?
    raise TestFailed, "HUP not pending"
test_support.TestFailed: HUP not pending


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-05-30 09:15

Message:
Logged In: YES 
user_id=6656

My fault.  I'll dig.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562188&group_id=5470



From noreply@sourceforge.net  Thu May 30 15:06:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 May 2002 07:06:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-559884 ] imaplib.IMAP4.open() typo
Message-ID: <E17DQZM-0006nw-00@usw-sf-web3.sourceforge.net>

Bugs item #559884, was opened at 2002-05-23 18:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559884&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: imaplib.IMAP4.open() typo

Initial Comment:
Looking at imaplib.py, class IMAP4, method open(),
there are two arguments, host and port, which are never
used in the method.  Instead, self.host and self.port
(set only in __init__) are used.  This gives a
misleading notion of what open() does.  I suggest that
these arguments be removed, because currently an IMAP4
object cannot be open()ed later by an external user,
i.e., open() is really private.

----------------------------------------------------------------------

>Comment By: Erik Demaine (edemaine)
Date: 2002-05-30 10:06

Message:
Logged In: YES 
user_id=265183

Looks OK, but shouldn't self.host and self.port be set if
they are specified in open()?  (Presumably in case another
method wants to use them.)  See attached alternative patch.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-24 10:36

Message:
Logged In: YES 
user_id=80475

The two arguments are needed because open() can be 
overridden in a sub-class.

Suggest testing to see if arguments are supplied and using 
them instead of self.host and self.port.  See attached 
patch.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559884&group_id=5470



From noreply@sourceforge.net  Thu May 30 20:08:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 May 2002 12:08:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-562552 ] build problems on DEC Unix 4.0f
Message-ID: <E17DVHp-0007im-00@usw-sf-web4.sourceforge.net>

Bugs item #562552, was opened at 2002-05-30 19:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562552&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Garey Mills (gareytm)
Assigned to: Nobody/Anonymous (nobody)
Summary: build problems on DEC Unix 4.0f

Initial Comment:
Building with cc instead of gcc (as recommended) and with configure switch '--with-dec-threads' (also 
recommended. 'make test yields the following errors and messages:

test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')

test test_format produced unexpected output:
**********************************************************************
*** lines 2-3 of actual output doesn't appear in expected output after line 1:
+ '%#o' % 0 == '00' != '0'
+ u'%#o' % 0 == u'00' != '0'
**********************************************************************


2 tests failed:
    test_bsddb test_format
27 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_minidom test_nis test_ntpath test_pyexpat
    test_rgbimg test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_unicode_file test_winreg test_winsound
    test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.


Are test failures important? Who do I ask "to teach regrtest.py about which tests are expected to get 
skipped on osf1V4"?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562552&group_id=5470



From noreply@sourceforge.net  Thu May 30 21:27:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 May 2002 13:27:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-562585 ] build problems on DEC Unix 4.0f
Message-ID: <E17DWWP-0001mD-00@usw-sf-web3.sourceforge.net>

Bugs item #562585, was opened at 2002-05-30 20:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562585&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Garey Mills (gareytm)
Assigned to: Nobody/Anonymous (nobody)
Summary: build problems on DEC Unix 4.0f

Initial Comment:
Building with cc instead of gcc (as recommended) and with configure switch '--with-dec-threads' (also 
recommended. 'make test yields the following errors and messages:

test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')

test test_format produced unexpected output:
**********************************************************************
*** lines 2-3 of actual output doesn't appear in expected output after line 1:
+ '%#o' % 0 == '00' != '0'
+ u'%#o' % 0 == u'00' != '0'
**********************************************************************


2 tests failed:
    test_bsddb test_format
27 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_minidom test_nis test_ntpath test_pyexpat
    test_rgbimg test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_unicode_file test_winreg test_winsound
    test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.


Are test failures important? Who do I ask "to teach regrtest.py about which tests are expected to get 
skipped on osf1V4"?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562585&group_id=5470



From noreply@sourceforge.net  Thu May 30 23:15:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 May 2002 15:15:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-562552 ] build problems on DEC Unix 4.0f
Message-ID: <E17DYCr-0001R0-00@usw-sf-web4.sourceforge.net>

Bugs item #562552, was opened at 2002-05-30 21:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562552&group_id=5470

Category: Build
Group: Python 2.2.1
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Garey Mills (gareytm)
Assigned to: Nobody/Anonymous (nobody)
Summary: build problems on DEC Unix 4.0f

Initial Comment:
Building with cc instead of gcc (as recommended) and with configure switch '--with-dec-threads' (also 
recommended. 'make test yields the following errors and messages:

test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')

test test_format produced unexpected output:
**********************************************************************
*** lines 2-3 of actual output doesn't appear in expected output after line 1:
+ '%#o' % 0 == '00' != '0'
+ u'%#o' % 0 == u'00' != '0'
**********************************************************************


2 tests failed:
    test_bsddb test_format
27 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_minidom test_nis test_ntpath test_pyexpat
    test_rgbimg test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_unicode_file test_winreg test_winsound
    test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.


Are test failures important? Who do I ask "to teach regrtest.py about which tests are expected to get 
skipped on osf1V4"?

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-31 00:15

Message:
Logged In: YES 
user_id=21627

Duplicate of 562585


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562552&group_id=5470



From noreply@sourceforge.net  Thu May 30 23:18:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 May 2002 15:18:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-562585 ] build problems on DEC Unix 4.0f
Message-ID: <E17DYFt-0001T9-00@usw-sf-web4.sourceforge.net>

Bugs item #562585, was opened at 2002-05-30 22:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562585&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Garey Mills (gareytm)
Assigned to: Nobody/Anonymous (nobody)
Summary: build problems on DEC Unix 4.0f

Initial Comment:
Building with cc instead of gcc (as recommended) and with configure switch '--with-dec-threads' (also 
recommended. 'make test yields the following errors and messages:

test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')

test test_format produced unexpected output:
**********************************************************************
*** lines 2-3 of actual output doesn't appear in expected output after line 1:
+ '%#o' % 0 == '00' != '0'
+ u'%#o' % 0 == u'00' != '0'
**********************************************************************


2 tests failed:
    test_bsddb test_format
27 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_minidom test_nis test_ntpath test_pyexpat
    test_rgbimg test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_unicode_file test_winreg test_winsound
    test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.


Are test failures important? Who do I ask "to teach regrtest.py about which tests are expected to get 
skipped on osf1V4"?

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-31 00:18

Message:
Logged In: YES 
user_id=21627

the test_format bug is not important; it indicates a bug in
the system's C library.

For recording expected skipped tests, see Lib/regrtest.py.
Search for win32, and submit a patch that records the
expected skips. Alternatively, just don't worry about this.

For test_:bsddb, please run "python Lib/regrtest.py -v
test_bsddb" separately, and report the output.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562585&group_id=5470



From noreply@sourceforge.net  Thu May 30 23:19:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 May 2002 15:19:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-562552 ] build problems on DEC Unix 4.0f
Message-ID: <E17DYGx-0001UF-00@usw-sf-web4.sourceforge.net>

Bugs item #562552, was opened at 2002-05-30 19:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562552&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Garey Mills (gareytm)
Assigned to: Nobody/Anonymous (nobody)
Summary: build problems on DEC Unix 4.0f

Initial Comment:
Building with cc instead of gcc (as recommended) and with configure switch '--with-dec-threads' (also 
recommended. 'make test yields the following errors and messages:

test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')

test test_format produced unexpected output:
**********************************************************************
*** lines 2-3 of actual output doesn't appear in expected output after line 1:
+ '%#o' % 0 == '00' != '0'
+ u'%#o' % 0 == u'00' != '0'
**********************************************************************


2 tests failed:
    test_bsddb test_format
27 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_minidom test_nis test_ntpath test_pyexpat
    test_rgbimg test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_unicode_file test_winreg test_winsound
    test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.


Are test failures important? Who do I ask "to teach regrtest.py about which tests are expected to get 
skipped on osf1V4"?

----------------------------------------------------------------------

>Comment By: Garey Mills (gareytm)
Date: 2002-05-30 22:19

Message:
Logged In: YES 
user_id=555793

Yes, sorry about that. Would you delete one? I can't.

Garey Mills

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-30 22:15

Message:
Logged In: YES 
user_id=21627

Duplicate of 562585


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562552&group_id=5470



From noreply@sourceforge.net  Thu May 30 23:22:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 May 2002 15:22:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-559429 ] __gxx_personality_v0 not found by ld
Message-ID: <E17DYJZ-00036m-00@usw-sf-web3.sourceforge.net>

Bugs item #559429, was opened at 2002-05-23 02:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559429&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: george r. goffe (grgoffe)
Assigned to: Nobody/Anonymous (nobody)
Summary: __gxx_personality_v0 not found by ld

Initial Comment:

Howdy,

I'm building Python-2.2.1 on a solaris 2.8 system and
am having trouble. The loader can not find the above
named external reference.

I'm enclosing the build log that shows (probably) more
than you ever wanted to know but it DOES show the
problem.

Any/all help/hints/tips would be appreciated.

Regards,

George...

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-31 00:22

Message:
Logged In: YES 
user_id=21627

This looks like a bug in your gcc installation. Python does
not define or use a symbol of that name.

You haven't actually enclosed the build log, but I don't
think this is necessary - it's a bug of your system. If you
disagree, please report the gcc version.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-24 21:15

Message:
Logged In: NO 

Hi,

I'm looking at the same problem in the same environment.

I could fix the failed compilation by changing gcc by g++,
which means that the --with-cxx=g++ option passed to
configure did not have the expected effect.

Regards,

R. Berber


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559429&group_id=5470



From noreply@sourceforge.net  Thu May 30 23:40:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 May 2002 15:40:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-562585 ] build problems on DEC Unix 4.0f
Message-ID: <E17DYb4-0007b6-00@usw-sf-web1.sourceforge.net>

Bugs item #562585, was opened at 2002-05-30 20:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562585&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Garey Mills (gareytm)
Assigned to: Nobody/Anonymous (nobody)
Summary: build problems on DEC Unix 4.0f

Initial Comment:
Building with cc instead of gcc (as recommended) and with configure switch '--with-dec-threads' (also 
recommended. 'make test yields the following errors and messages:

test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')

test test_format produced unexpected output:
**********************************************************************
*** lines 2-3 of actual output doesn't appear in expected output after line 1:
+ '%#o' % 0 == '00' != '0'
+ u'%#o' % 0 == u'00' != '0'
**********************************************************************


2 tests failed:
    test_bsddb test_format
27 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_minidom test_nis test_ntpath test_pyexpat
    test_rgbimg test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_unicode_file test_winreg test_winsound
    test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.


Are test failures important? Who do I ask "to teach regrtest.py about which tests are expected to get 
skipped on osf1V4"?

----------------------------------------------------------------------

>Comment By: Garey Mills (gareytm)
Date: 2002-05-30 22:40

Message:
Logged In: YES 
user_id=555793

Here are the command and output

# ./python Lib/test/regrtest.py -v test_bsddb
test_bsddb

Testing:  BTree
test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 305, in runtest
    the_module = __import__(test, globals(), locals(), [])
  File "./Lib/test/test_bsddb.py", line 76, in ?
    test(type[0], type[1])
  File "./Lib/test/test_bsddb.py", line 18, in test
    f = openmethod(fname, 'c')
error: (22, 'Invalid argument')
1 test failed:
    test_bsddb

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-30 22:18

Message:
Logged In: YES 
user_id=21627

the test_format bug is not important; it indicates a bug in
the system's C library.

For recording expected skipped tests, see Lib/regrtest.py.
Search for win32, and submit a patch that records the
expected skips. Alternatively, just don't worry about this.

For test_:bsddb, please run "python Lib/regrtest.py -v
test_bsddb" separately, and report the output.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562585&group_id=5470



From noreply@sourceforge.net  Thu May 30 23:59:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 May 2002 15:59:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-562552 ] build problems on DEC Unix 4.0f
Message-ID: <E17DYth-0001vC-00@usw-sf-web4.sourceforge.net>

Bugs item #562552, was opened at 2002-05-30 21:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562552&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Garey Mills (gareytm)
Assigned to: Nobody/Anonymous (nobody)
Summary: build problems on DEC Unix 4.0f

Initial Comment:
Building with cc instead of gcc (as recommended) and with configure switch '--with-dec-threads' (also 
recommended. 'make test yields the following errors and messages:

test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')

test test_format produced unexpected output:
**********************************************************************
*** lines 2-3 of actual output doesn't appear in expected output after line 1:
+ '%#o' % 0 == '00' != '0'
+ u'%#o' % 0 == u'00' != '0'
**********************************************************************


2 tests failed:
    test_bsddb test_format
27 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_minidom test_nis test_ntpath test_pyexpat
    test_rgbimg test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_unicode_file test_winreg test_winsound
    test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.


Are test failures important? Who do I ask "to teach regrtest.py about which tests are expected to get 
skipped on osf1V4"?

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-05-31 00:59

Message:
Logged In: YES 
user_id=21627

It's closed; it does not need to be deleted beyond that.

----------------------------------------------------------------------

Comment By: Garey Mills (gareytm)
Date: 2002-05-31 00:19

Message:
Logged In: YES 
user_id=555793

Yes, sorry about that. Would you delete one? I can't.

Garey Mills

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-31 00:15

Message:
Logged In: YES 
user_id=21627

Duplicate of 562585


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562552&group_id=5470



From noreply@sourceforge.net  Fri May 31 03:54:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 May 2002 19:54:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-559429 ] __gxx_personality_v0 not found by ld
Message-ID: <E17DcYW-0001hB-00@usw-sf-web1.sourceforge.net>

Bugs item #559429, was opened at 2002-05-22 17:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559429&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: george r. goffe (grgoffe)
Assigned to: Nobody/Anonymous (nobody)
Summary: __gxx_personality_v0 not found by ld

Initial Comment:

Howdy,

I'm building Python-2.2.1 on a solaris 2.8 system and
am having trouble. The loader can not find the above
named external reference.

I'm enclosing the build log that shows (probably) more
than you ever wanted to know but it DOES show the
problem.

Any/all help/hints/tips would be appreciated.

Regards,

George...

----------------------------------------------------------------------

>Comment By: george r. goffe (grgoffe)
Date: 2002-05-30 19:54

Message:
Logged In: YES 
user_id=293753

Howdy,

I'm attempting to attach the latest build log. The old
version of my gcc was 3.0.4. This version is with gcc-3.1.

Sorry about the foulup.

Regards and thanks for all your help and time.

George...



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-30 15:22

Message:
Logged In: YES 
user_id=21627

This looks like a bug in your gcc installation. Python does
not define or use a symbol of that name.

You haven't actually enclosed the build log, but I don't
think this is necessary - it's a bug of your system. If you
disagree, please report the gcc version.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-05-24 12:15

Message:
Logged In: NO 

Hi,

I'm looking at the same problem in the same environment.

I could fix the failed compilation by changing gcc by g++,
which means that the --with-cxx=g++ option passed to
configure did not have the expected effect.

Regards,

R. Berber


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=559429&group_id=5470



From noreply@sourceforge.net  Fri May 31 12:36:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 04:36:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-562878 ] xmlrpclib.Binary.data undocumented
Message-ID: <E17Dkhn-00037B-00@usw-sf-web3.sourceforge.net>

Bugs item #562878, was opened at 2002-05-31 13:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562878&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xmlrpclib.Binary.data undocumented

Initial Comment:
There is no documentation on how to get at the data in 
a Binary objects. Likewise for DateTime.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562878&group_id=5470



From noreply@sourceforge.net  Fri May 31 13:33:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 05:33:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-562892 ] use python if not pass test format??
Message-ID: <E17Dlau-0001Fp-00@usw-sf-web2.sourceforge.net>

Bugs item #562892, was opened at 2002-05-31 07:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562892&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: ellen davis (ellendavis)
Assigned to: Nobody/Anonymous (nobody)
Summary: use python if not pass test format??

Initial Comment:

I have built pythin 2.2.1 on my Tru64 4.0F AlphapServer.  It builds OK, but does not pass test_format.  
>From previous posts, I found that the libc on Tru64 is broken (not ansi compliant), and that is the reason 
the test fails.  

I have a user in need on python today.  Is it safe to use the python binary, even though the test_format 
failed?  



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562892&group_id=5470



From noreply@sourceforge.net  Fri May 31 15:09:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 07:09:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-561825 ] Confusing error for "del f()"
Message-ID: <E17Dn6H-0002NI-00@usw-sf-web2.sourceforge.net>

Bugs item #561825, was opened at 2002-05-29 07:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561825&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Confusing error for "del f()"

Initial Comment:
>>> del f()
SyntaxError: can't assign to function call

I think this should be something more like:

SyntaxError: can't delete function call

I'm using Python 2.2.1 on Windows.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-05-31 14:09

Message:
Logged In: YES 
user_id=31392

Fixed in rev. 2.245 of compile.c.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561825&group_id=5470



From noreply@sourceforge.net  Fri May 31 17:03:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 09:03:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-561770 ] re module MatchObject.group() problems
Message-ID: <E17Doru-00065j-00@usw-sf-web3.sourceforge.net>

Bugs item #561770, was opened at 2002-05-29 04:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561770&group_id=5470

Category: Extension Modules
>Group: Not a Bug
Status: Open
>Resolution: Wont Fix
Priority: 5
Submitted By: Christian Lavoie (christianlavoie)
Assigned to: Fredrik Lundh (effbot)
Summary: re module MatchObject.group() problems

Initial Comment:
Test case:  
  
 #!/usr/bin/env python2.2  
  
import re  
  
test = re.compile('^([\w]*)(?:[\s]*)([\w]*)(?:, ([\w]*))*$')  
  
print test.match('deny ssh, https, x11, ldap,  
albert').groups()  
print test.match('deny ssh').groups()  
  
------  
  
Output of the test case:  
  
('deny', 'ssh', 'albert')  
('deny', 'ssh', None)  
  
----  
  
It is my opinion and the opinion of my Perl savvy friend  
that this is just plain wrong.  
  
We both think the output should have been:  
  
('deny', 'ssh')  
('deny', 'ssh', 'https', x11', 'ldap', 'albert')  
  
-----  
  
(Don't worry about the albert protocol)  
  
That is, that parenthesis grouping should be numbered  
by the order they appear in the matched target string, 
instead of by the order they appear in the  
regular expression. 
 
Have fun, 
Chris 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-29 18:11

Message:
Logged In: YES 
user_id=80475

I think group numbering is correct as is because:
1.  The behavior matches the documentation
2.  It is useful so that the \1 \2 substitutions can be 
calculated before runtime
3.  From my brief perusal of Perl docs, this matches Perl 
behavior also
4.  Order of match doesn't make sense with hierarchial 
groupings where match may belong to both an inner and 
outer group.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561770&group_id=5470



From noreply@sourceforge.net  Fri May 31 17:03:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 09:03:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-561770 ] re module MatchObject.group() problems
Message-ID: <E17DosH-00065q-00@usw-sf-web3.sourceforge.net>

Bugs item #561770, was opened at 2002-05-29 04:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561770&group_id=5470

Category: Extension Modules
Group: Not a Bug
>Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Christian Lavoie (christianlavoie)
Assigned to: Fredrik Lundh (effbot)
Summary: re module MatchObject.group() problems

Initial Comment:
Test case:  
  
 #!/usr/bin/env python2.2  
  
import re  
  
test = re.compile('^([\w]*)(?:[\s]*)([\w]*)(?:, ([\w]*))*$')  
  
print test.match('deny ssh, https, x11, ldap,  
albert').groups()  
print test.match('deny ssh').groups()  
  
------  
  
Output of the test case:  
  
('deny', 'ssh', 'albert')  
('deny', 'ssh', None)  
  
----  
  
It is my opinion and the opinion of my Perl savvy friend  
that this is just plain wrong.  
  
We both think the output should have been:  
  
('deny', 'ssh')  
('deny', 'ssh', 'https', x11', 'ldap', 'albert')  
  
-----  
  
(Don't worry about the albert protocol)  
  
That is, that parenthesis grouping should be numbered  
by the order they appear in the matched target string, 
instead of by the order they appear in the  
regular expression. 
 
Have fun, 
Chris 

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-29 18:11

Message:
Logged In: YES 
user_id=80475

I think group numbering is correct as is because:
1.  The behavior matches the documentation
2.  It is useful so that the \1 \2 substitutions can be 
calculated before runtime
3.  From my brief perusal of Perl docs, this matches Perl 
behavior also
4.  Order of match doesn't make sense with hierarchial 
groupings where match may belong to both an inner and 
outer group.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561770&group_id=5470



From noreply@sourceforge.net  Fri May 31 20:41:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 12:41:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-563060 ] Module can be used as a base class
Message-ID: <E17DsHG-0006Ez-00@usw-sf-web4.sourceforge.net>

Bugs item #563060, was opened at 2002-05-31 15:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563060&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module can be used as a base class

Initial Comment:
>From python-dev:

> But this is not what I would expect:
> 
>       >>> import string
>       >>> class newstr(string): pass
>       ... 
>       # i would have expected this to raise a TypeError
>       >>> x = newstr()
>       Traceback (most recent call last):
>         File "<stdin>", line 1, in ?
>       TypeError: 'module' object is not callable
> 
> Perhaps this error should be handled when the class
is constructed
> rather than when instantiating an object?

Guido says "the bug is that you can use any module as a
base class"

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563060&group_id=5470



From noreply@sourceforge.net  Fri May 31 21:27:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 13:27:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-563060 ] Module can be used as a base class
Message-ID: <E17Dszh-0000S1-00@usw-sf-web3.sourceforge.net>

Bugs item #563060, was opened at 2002-05-31 19:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563060&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Module can be used as a base class

Initial Comment:
>From python-dev:

> But this is not what I would expect:
> 
>       >>> import string
>       >>> class newstr(string): pass
>       ... 
>       # i would have expected this to raise a TypeError
>       >>> x = newstr()
>       Traceback (most recent call last):
>         File "<stdin>", line 1, in ?
>       TypeError: 'module' object is not callable
> 
> Perhaps this error should be handled when the class
is constructed
> rather than when instantiating an object?

Guido says "the bug is that you can use any module as a
base class"

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2002-05-31 20:27

Message:
Logged In: YES 
user_id=56214

More specifically, ModuleType's constructor accepts and
ignores a (name,bases,dict) call signature.  Other objects
will fail at class construction time like this:

>>> class d({}): pass

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in ?
    class d({}): pass
TypeError: dict() takes at most 1 argument (3 given)
>>> class n(1): pass

Traceback (most recent call last):
  File "<pyshell#3>", line 1, in ?
    class n(1): pass
TypeError: int() takes at most 2 arguments (3 given)
>>> class s("s"): pass

Traceback (most recent call last):
  File "<pyshell#5>", line 1, in ?
    class s("s"): pass
TypeError: str() takes at most 1 argument (3 given)
>>> 

Since the module constructor doesn't actually need any
arguments, it should complain the same way the above items do.

Interestingly, while type(module) doesn't complain when
called with excess arguments, the function 'new.module'
does.  Ironically, the docstring for new.module seems to
imply it takes an argument.  Perhaps new.module should
simply refer to type(module), once the latter is fixed.

Another, far more radical fix for this bug would be to
change the constructor to accept the (name,bases,dict)
signature, thus making it possible to subclass a module and
have it work correctly, for some value of "correctly".  :)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=563060&group_id=5470



From noreply@sourceforge.net  Fri May 31 22:00:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 14:00:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-492349 ] detail: tp_basicsize and tp_itemsize
Message-ID: <E17DtVe-0006yW-00@usw-sf-web4.sourceforge.net>

Bugs item #492349, was opened at 2001-12-12 23:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492349&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: detail: tp_basicsize and tp_itemsize

Initial Comment:
> Here's another question: for extensible types (which
can grow beyond
> tp_basicsize), I am guessing you give no guarantees
about the aligment of
> the following elements, so it's up to the programmer
to make sure that
> tp_basicsize is a multiple of the alignment of
whatever's being put in the
> extensible area.
> 
> If that's true, I think the docs should say so.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-31 17:00

Message:
Logged In: YES 
user_id=6380

I've added a note to newtypes.tex.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=492349&group_id=5470



From noreply@sourceforge.net  Fri May 31 22:02:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 14:02:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-560438 ] foo() doesn't use __getattribute__
Message-ID: <E17DtXU-0006zm-00@usw-sf-web4.sourceforge.net>

Bugs item #560438, was opened at 2002-05-25 08:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560438&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Nobody/Anonymous (nobody)
Summary: foo() doesn't use __getattribute__

Initial Comment:
In the Python 2.2 release notes, it says::

- For new-style classes, what was previously called
__getattr__ is now
  called __getattribute__.  This method, if defined, is
called for
  *every* attribute access.  

However, if I define a callable class that also defines
a __getattribute__ method, the __getattribute__ method
is not used when I say instance().

class Foo(object):

    def __getattribute__(self, name):
        print "__getattribute__ with name =",name
        if name=="__call__":
            return lambda:1
        object.__getattribute__(self, name)

    def __call__(self):
        print "__call__ method called"
        
f = Foo()
f.__call__()
f()

$ python /tmp/test.py
__getattribute__ with name = __call__
__call__ method called

I would expect the second line of output to be the same
as the first.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2002-05-31 21:02

Message:
Logged In: YES 
user_id=56214

This looks like behavior that is "as designed".  The
existence of a __call__ attribute is predicated upon
callability, *not* the other way around.  Or to put it
another way, callability is decided by an object's type, not
its instance attributes.  By way of contrasting example,
consider that if you set a '__call__' attribute on a module,
that doesn't make the module callable!

While this is not consistent with old-style class behavior,
I don't think changing it to match old-style classes is
consistent with type/class unification.  If you need to be
able to compute the __call__ attribute, the simple way is to
use a property or other attribute descriptor, e.g.:

def __call__(self):
    return lambda: 1

__call__ = property(__call__)

I'm not sure which other magic attributes are amenable to
this sort of treatment, however.


----------------------------------------------------------------------

Comment By: Steve Alexander (stevea_zope)
Date: 2002-05-25 09:05

Message:
Logged In: YES 
user_id=492001

Properly formatted test case in uploaded file.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560438&group_id=5470



From noreply@sourceforge.net  Fri May 31 22:16:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 14:16:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-560438 ] foo() doesn't use __getattribute__
Message-ID: <E17Dtkf-0000wR-00@usw-sf-web3.sourceforge.net>

Bugs item #560438, was opened at 2002-05-25 08:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560438&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Nobody/Anonymous (nobody)
Summary: foo() doesn't use __getattribute__

Initial Comment:
In the Python 2.2 release notes, it says::

- For new-style classes, what was previously called
__getattr__ is now
  called __getattribute__.  This method, if defined, is
called for
  *every* attribute access.  

However, if I define a callable class that also defines
a __getattribute__ method, the __getattribute__ method
is not used when I say instance().

class Foo(object):

    def __getattribute__(self, name):
        print "__getattribute__ with name =",name
        if name=="__call__":
            return lambda:1
        object.__getattribute__(self, name)

    def __call__(self):
        print "__call__ method called"
        
f = Foo()
f.__call__()
f()

$ python /tmp/test.py
__getattribute__ with name = __call__
__call__ method called

I would expect the second line of output to be the same
as the first.

----------------------------------------------------------------------

>Comment By: Steve Alexander (stevea_zope)
Date: 2002-05-31 21:16

Message:
Logged In: YES 
user_id=492001

Thanks for the thoughts Phillip.

I agree with what you say about the existence of a __call__
attribute beingn predicated upon callability.

However, I don't think that is relevant to my example.

My example class Foo is callable. I define the __call__
method. However, on calling a foo instance, the __call__
method is called, whereas according to the documentation, if
calling an object includes an attribute access, 
__getattribute__ should be called.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2002-05-31 21:02

Message:
Logged In: YES 
user_id=56214

This looks like behavior that is "as designed".  The
existence of a __call__ attribute is predicated upon
callability, *not* the other way around.  Or to put it
another way, callability is decided by an object's type, not
its instance attributes.  By way of contrasting example,
consider that if you set a '__call__' attribute on a module,
that doesn't make the module callable!

While this is not consistent with old-style class behavior,
I don't think changing it to match old-style classes is
consistent with type/class unification.  If you need to be
able to compute the __call__ attribute, the simple way is to
use a property or other attribute descriptor, e.g.:

def __call__(self):
    return lambda: 1

__call__ = property(__call__)

I'm not sure which other magic attributes are amenable to
this sort of treatment, however.


----------------------------------------------------------------------

Comment By: Steve Alexander (stevea_zope)
Date: 2002-05-25 09:05

Message:
Logged In: YES 
user_id=492001

Properly formatted test case in uploaded file.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=560438&group_id=5470



From noreply@sourceforge.net  Fri May 31 22:26:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 14:26:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-533625 ] rexec: potential security hole
Message-ID: <E17Dtuj-0007Df-00@usw-sf-web4.sourceforge.net>

Bugs item #533625, was opened at 2002-03-22 10:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Guido van Rossum (gvanrossum)
Summary: rexec: potential security hole

Initial Comment:
The documentation of the restricted execution module, 
rexec, should make it clear that it is dangerous to 
allow the restricted code write into a directory that 
is included in sys.path. Indeed, I suspect that is it 
common to allow restricted code to write in the 
current directory (e.g. after a chdir() to a directory 
that contains only the files we want the restricted 
code to work on). But '' is in sys.path by default.

Attached is a script that uses this to perform the 
equivalent of an unmarshal of a code object (which is 
forbidden in restricted mode -- although it is clear 
to me why, it might not be obvious to someone not used 
to Python's internals and should be mentionned 
somewhere). The attached script writes and then import 
a .pyc file that defines a function whose bogus code 
(at least on 32-bit Unix machines with Python 2.2-2.3) 
returns the frame of the caller. This lets the 
restricted code access the original builtins.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-31 17:26

Message:
Logged In: YES 
user_id=6380

I've checked this in now, in 2.1, 2.2 and 2.3.  Thanks!

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-04-07 06:08

Message:
Logged In: YES 
user_id=4771

I uploaded a patch for the documentation.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-25 12:02

Message:
Logged In: YES 
user_id=6380

Thanks. I'll have to think about this some more. I guess
it's easy enough to document that one can get performance
back by adding imp.PY_COMPILED to ok_file_types.

I've added a context diff (1) to make your patch less
suscpetible to going stale (2) to use a list comprehension
instead of filter().

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-03-25 09:06

Message:
Logged In: YES 
user_id=4771

Ok. This patch prevents the default module loader hooks 
used by RExec to locate any PY_COMPILED file. I added an 
ok_file_types tuple to RExec that lists the file types we 
should allow loading from -- currently only C_EXTENSION and 
PY_SOURCE.

I can add the above comment to the docs as well if the 
patch is acceptable.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-24 16:41

Message:
Logged In: YES 
user_id=6380

Good points, Armin. I guess it's unlikely to have a site
that allows limited read-write for some rexec clients and
read-only for others, but not impossible.

Could I twist your arm and ask for a patch?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-03-24 10:00

Message:
Logged In: YES 
user_id=4771

This could be defeated by a double attack: one rexec'ed 
code leaves a .pyc file in a temporary directory, and later 
another rexec'ed code in a fully read-only environment 
imports it. Or the buggy .pyc file was put there with some 
other tool (e.g. ftp to /incoming).

To be on the safe side one could completely disable loading 
from .pyc files. This has the advantage of automatically 
fixing the problem in all of the existing applications. I 
don't know if this would be a serious performance problem --
 rexec'ed code might generally don't import too much 
standard modules itself anyway. One could later add 
a "safe_path" list that lists the directories from which 
loading .pyc files is considered to be safe.

Note that the default hooks are such that no .pyc files are 
ever *written* by imports from rexec'ed code. One can thus 
guess that no existing rexec'ed code relies on .pyc file 
performance for anything but the standard library.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:53

Message:
Logged In: YES 
user_id=6380

Note that rexec as shipped doesn't allow writing any files,
so it's only a security hole in apps that modify open() to
allow writing in some directory. I guess the rexec import
code could be made aware of which directories are writable
and skip those if they appear on sys.path.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:50

Message:
Logged In: YES 
user_id=6380

Martin: I don't think so. Adding range check to the VM would
slow it down considerably, especially since it affects all
the "fast" opcodes. In order to make the VM totally robust,
you would also have to fix the various push and pop opcodes
(or the macros) to check for stack overflow and underflow as
well. For better or for worse, the assumption of the VM is
that the compiler generates "perfect" bytecode, and we do
*not* have a bytecode verifier like Java. For trusted code,
I don't mind. For untrusted code, rexec should disallow any
manipulation of code objects. 

Armin has found a real security hole -- fortunately the
default is not to allow writing at all, but in fact, having
any writable directories at all opens up the hole, since
restricted code can changes its own sys.path!!!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 12:35

Message:
Logged In: YES 
user_id=21627

Isn't that a bug in LOAD_FAST?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470



From noreply@sourceforge.net  Fri May 31 23:12:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 15:12:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-562585 ] build problems on DEC Unix 4.0f
Message-ID: <E17Dud5-0007Rs-00@usw-sf-web2.sourceforge.net>

Bugs item #562585, was opened at 2002-05-30 22:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562585&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Garey Mills (gareytm)
Assigned to: Nobody/Anonymous (nobody)
Summary: build problems on DEC Unix 4.0f

Initial Comment:
Building with cc instead of gcc (as recommended) and with configure switch '--with-dec-threads' (also 
recommended. 'make test yields the following errors and messages:

test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')

test test_format produced unexpected output:
**********************************************************************
*** lines 2-3 of actual output doesn't appear in expected output after line 1:
+ '%#o' % 0 == '00' != '0'
+ u'%#o' % 0 == u'00' != '0'
**********************************************************************


2 tests failed:
    test_bsddb test_format
27 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_minidom test_nis test_ntpath test_pyexpat
    test_rgbimg test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_unicode_file test_winreg test_winsound
    test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.


Are test failures important? Who do I ask "to teach regrtest.py about which tests are expected to get 
skipped on osf1V4"?

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-06-01 00:12

Message:
Logged In: YES 
user_id=21627

Can you please edit the fragment in test_bsddb.py that reads

    f = openmethod(fname, 'c')

to print fname before that line? Apparently, mktemp returns
a bad file name.

----------------------------------------------------------------------

Comment By: Garey Mills (gareytm)
Date: 2002-05-31 00:40

Message:
Logged In: YES 
user_id=555793

Here are the command and output

# ./python Lib/test/regrtest.py -v test_bsddb
test_bsddb

Testing:  BTree
test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 305, in runtest
    the_module = __import__(test, globals(), locals(), [])
  File "./Lib/test/test_bsddb.py", line 76, in ?
    test(type[0], type[1])
  File "./Lib/test/test_bsddb.py", line 18, in test
    f = openmethod(fname, 'c')
error: (22, 'Invalid argument')
1 test failed:
    test_bsddb

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-31 00:18

Message:
Logged In: YES 
user_id=21627

the test_format bug is not important; it indicates a bug in
the system's C library.

For recording expected skipped tests, see Lib/regrtest.py.
Search for win32, and submit a patch that records the
expected skips. Alternatively, just don't worry about this.

For test_:bsddb, please run "python Lib/regrtest.py -v
test_bsddb" separately, and report the output.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562585&group_id=5470



From noreply@sourceforge.net  Fri May 31 23:32:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 15:32:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-561858 ] Assertion with very long lists
Message-ID: <E17Duwm-0007w0-00@usw-sf-web4.sourceforge.net>

Bugs item #561858, was opened at 2002-05-29 06:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jerome Alet (jalet)
Assigned to: Nobody/Anonymous (nobody)
Summary: Assertion with very long lists

Initial Comment:
I've tried to import a module which only define a list
of 170000 elements (a word list) which defines an
element per line, so the module also has 170000 lines
in it. Here's the error :

--- CUT ---
Python 2.1.3 (#1, Apr 20 2002, 10:14:34) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import dictionnaire
python: ../Python/ceval.c:695: eval_code2: Assertion
`(stack_pointer - f->f_valuestack) <= f->f_stacksize'
failed.
Abandon
--- CUT ---

this seems to be the same problem as bug id 210647 but
there's no segfault.

the module is attached to this bug report.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-05-31 18:32

Message:
Logged In: YES 
user_id=33168

I think there are several problems here.
I was able to narrow down at least one problem to a long list.
It doesn't seem to have anything to do w/backslashes.

There seems to be an interaction with importing the module.
If the long list is in __main__, the problem does not occur.
The problem only occurs when the list is in an imported module
and only after importing it the second time (after the .pyc
is created).

If a list has 32768+ items there seems to be a memory problem.
There is an exception, then a crash.  Here's the exception:

TypeError: unsupported operand type(s) for &: 'str' and 'str'

Here's a stack trace against CVS version:

#0  chunk_free (ar_ptr=0x401b1620, p=0x8156a10) at malloc.c:3180
#1  0x400fdbf4 in __libc_free (mem=0x8156a18) at malloc.c:3154
#2  0x0805c0db in list_dealloc (op=0x401c4eac) at
Objects/listobject.c:214
#3  0x080c7618 in PyDict_SetItem (op=0x401bd79c,
key=0x401c4ec0, 
    value=0x80e185c) at Objects/dictobject.c:373
#4  0x080c93f9 in PyDict_SetItemString (v=0x401bd79c,
key=0x80d9070 "path", 
    item=0x80e185c) at Objects/dictobject.c:1895
#5  0x08099ad8 in PyImport_Cleanup () at Python/import.c:286
#6  0x080a266d in Py_Finalize () at Python/pythonrun.c:228
#7  0x08053766 in Py_Main (argc=2, argv=0xbffff904) at
Modules/main.c:379


----------------------------------------------------------------------

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 08:42

Message:
Logged In: YES 
user_id=97214

I've done more tests, the bug only occurs if every line has
a backslash at its end :

liste = [ \
            "item0", \
            "item1", \
            # ... many many lines
            "itemN" ]

and it works if I remove the \ from each end of line.

hth.

----------------------------------------------------------------------

Comment By: Jerome Alet (jalet)
Date: 2002-05-29 06:14

Message:
Logged In: YES 
user_id=97214

module too long to be attached. ask it by email at
alet@librelogiciel.com if needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=561858&group_id=5470



From noreply@sourceforge.net  Fri May 31 23:47:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 May 2002 15:47:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-562585 ] build problems on DEC Unix 4.0f
Message-ID: <E17DvBe-00085q-00@usw-sf-web4.sourceforge.net>

Bugs item #562585, was opened at 2002-05-30 20:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562585&group_id=5470

Category: Build
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Garey Mills (gareytm)
Assigned to: Nobody/Anonymous (nobody)
Summary: build problems on DEC Unix 4.0f

Initial Comment:
Building with cc instead of gcc (as recommended) and with configure switch '--with-dec-threads' (also 
recommended. 'make test yields the following errors and messages:

test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')

test test_format produced unexpected output:
**********************************************************************
*** lines 2-3 of actual output doesn't appear in expected output after line 1:
+ '%#o' % 0 == '00' != '0'
+ u'%#o' % 0 == u'00' != '0'
**********************************************************************


2 tests failed:
    test_bsddb test_format
27 tests skipped:
    test_al test_audioop test_cd test_cl test_curses test_dl test_gdbm
    test_gl test_gzip test_imageop test_imgfile test_linuxaudiodev
    test_locale test_minidom test_nis test_ntpath test_pyexpat
    test_rgbimg test_sax test_socket_ssl test_socketserver
    test_sunaudiodev test_unicode_file test_winreg test_winsound
    test_zipfile test_zlib
Ask someone to teach regrtest.py about which tests are
expected to get skipped on osf1V4.


Are test failures important? Who do I ask "to teach regrtest.py about which tests are expected to get 
skipped on osf1V4"?

----------------------------------------------------------------------

>Comment By: Garey Mills (gareytm)
Date: 2002-05-31 22:47

Message:
Logged In: YES 
user_id=555793

Here is the output of the test with the file name:

# ./python Lib/test/regrtest.py -v test_bsddb
test_bsddb

Testing:  BTree

fname:  /tmp/@18218.0
test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 305, in runtest
    the_module = __import__(test, globals(), locals(), [])
  File "Lib/test/test_bsddb.py", line 79, in ?
    test(type[0], type[1])
  File "Lib/test/test_bsddb.py", line 21, in test
    f = openmethod(fname, 'c')
error: (22, 'Invalid argument')
1 test failed:
    test_bsddb

Garey

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-31 22:12

Message:
Logged In: YES 
user_id=21627

Can you please edit the fragment in test_bsddb.py that reads

    f = openmethod(fname, 'c')

to print fname before that line? Apparently, mktemp returns
a bad file name.

----------------------------------------------------------------------

Comment By: Garey Mills (gareytm)
Date: 2002-05-30 22:40

Message:
Logged In: YES 
user_id=555793

Here are the command and output

# ./python Lib/test/regrtest.py -v test_bsddb
test_bsddb

Testing:  BTree
test test_bsddb crashed -- bsddb.error: (22, 'Invalid argument')
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 305, in runtest
    the_module = __import__(test, globals(), locals(), [])
  File "./Lib/test/test_bsddb.py", line 76, in ?
    test(type[0], type[1])
  File "./Lib/test/test_bsddb.py", line 18, in test
    f = openmethod(fname, 'c')
error: (22, 'Invalid argument')
1 test failed:
    test_bsddb

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-05-30 22:18

Message:
Logged In: YES 
user_id=21627

the test_format bug is not important; it indicates a bug in
the system's C library.

For recording expected skipped tests, see Lib/regrtest.py.
Search for win32, and submit a patch that records the
expected skips. Alternatively, just don't worry about this.

For test_:bsddb, please run "python Lib/regrtest.py -v
test_bsddb" separately, and report the output.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=562585&group_id=5470