From noreply at sourceforge.net  Sun Feb  1 11:29:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  1 11:29:50 2004
Subject: [ python-Bugs-888594 ] cPickle doesn't like protocol keyword
	argument, pickle does
Message-ID: <E1AnKTh-00074Y-00@sc8-sf-web3.sourceforge.net>

Bugs item #888594, was opened at 2004-02-01 17:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=888594&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle doesn't like protocol keyword argument, pickle does

Initial Comment:
The dump and dumps functions from the "cPickle" module
don't accept the protocol keyword argument. The
"pickle" module does. This is an irritating API
difference that requires me to write different code to
deal with either cPickle or pickle (if cPickle is not
available).

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

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

From noreply at sourceforge.net  Sun Feb  1 21:53:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  1 21:53:57 2004
Subject: [ python-Bugs-888829 ] FAQ 2.3 slices not used
Message-ID: <E1AnUDh-0003RP-00@sc8-sf-web1.sourceforge.net>

Bugs item #888829, was opened at 2004-02-01 21:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=888829&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Wayne Folta (wfolta)
Assigned to: Nobody/Anonymous (nobody)
Summary: FAQ 2.3 slices not used

Initial Comment:
Python Programming FAQ 4.3

The "iterate through a list in reverse" answer doesn't add 
the 2.3 slice answer:

for x in list[::-1]
       <do something with x>

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

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

From noreply at sourceforge.net  Sun Feb  1 21:56:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  1 21:56:33 2004
Subject: [ python-Bugs-888830 ] POP3 lib timeout
Message-ID: <E1AnUGE-0002jj-00@sc8-sf-web2.sourceforge.net>

Bugs item #888830, was opened at 2004-02-01 21:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=888830&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Wayne Folta (wfolta)
Assigned to: Nobody/Anonymous (nobody)
Summary: POP3 lib timeout

Initial Comment:
Python Library Reference 11.9 poplib - POP3

Presently says, "One exception is defined as an attribute of 
the poplib module..."

Recommend adding:

"The POP3 library is built using the socket package and 
socket exceptions are not caught by POP3."

In fact, this might be a good sentence to add to most 
Internet packages.

I needed this info to figure out how to have a POP3 
connection timeout on a message download.

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

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

From noreply at sourceforge.net  Mon Feb  2 05:56:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb  2 05:56:18 2004
Subject: [ python-Bugs-881768 ] 2.3.3 hangs in test_fork1 and
	test_threadedtempfile
Message-ID: <E1AnbkT-0004I8-00@sc8-sf-web1.sourceforge.net>

Bugs item #881768, was opened at 2004-01-21 22:28
Message generated for change (Settings changed) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=881768&group_id=5470

Category: Threads
Group: Python 2.3
Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: David Dyck (dcd)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3.3 hangs in test_fork1 and test_threadedtempfile

Initial Comment:
make test hangs in 2.3.3 
 test_fork1 and test_threadedtempfile

go get test to complete I needed to 
 ./python -E -tt ./Lib/test/regrtest.py -l -x
test_fork1 -x test_threadedtempfile



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

Comment By: David Dyck (dcd)
Date: 2004-01-24 00:04

Message:
Logged In: YES 
user_id=53855

As I mentioned in the 2004-01-23 17:24 message,
I was able to make some more progress, using
  --without-threads
to disable the threads in v2.3.3   (e.g.)
 ./configure --without-threads && make

I should have done a make clean first !!!!
then I received less errors.

  (I'd like to mark this as "resolved" to
the point that linux/libc5 is not expected
to have functional threads, as I'm not
looking for threads in Python at this time)

I'll look into the other errors and report them
separately.   For now
  ./configure --without-threads
is effective enough.


*** WARNING: renaming "bsddb185" since importing it failed:
Unable to resolve symbol
*** WARNING: renaming "dbm" since importing it failed:
Unable to resolve symbol
*** WARNING: renaming "_curses" since importing it failed:
Unable to resolve symbol
*** WARNING: renaming "_curses_panel" since importing it
failed: No module named _curses


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

Comment By: David Dyck (dcd)
Date: 2004-01-23 17:24

Message:
Logged In: YES 
user_id=53855

I was able to make some more progress, using
--without-threads
to disable the threads in v2.3.3 
    ./configure --without-threads && make

but I was surprised how threads were twisted into the rest
of the python modules (or at least their test cases

*** WARNING: renaming "_testcapi" since importing it failed:
Unable to resolve s
*** WARNING: renaming "_socket" since importing it failed:
Unable to resolve sym
*** WARNING: renaming "bsddb185" since importing it failed:
Unable to resolve sy
*** WARNING: renaming "dbm" since importing it failed:
Unable to resolve symbol
*** WARNING: renaming "_curses" since importing it failed:
Unable to resolve sym
*** WARNING: renaming "zlib" since importing it failed:
Unable to resolve symbol


*** WARNING: renaming "_ssl" since importing it failed: No
module named _socket
*** WARNING: renaming "_curses_panel" since importing it
failed: No module named

It was surprising that zlib would depend on threads but
more detail reveals the following from the build:
./python: can't resolve symbol 'PyThread_acquire_lock'
./python: can't resolve symbol 'PyThread_allocate_lock'
./python: can't resolve symbol 'PyThread_release_lock'



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

Comment By: Michael Hudson (mwh)
Date: 2004-01-23 10:29

Message:
Logged In: YES 
user_id=6656

Fair enough, I suppose.  I doubt you'll get threads working
on such a system, though, as python tickles bugs in old
versions of pthreads.  You can try passing --disable-threads
(think that's the right incantation) to configure.

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

Comment By: David Dyck (dcd)
Date: 2004-01-23 05:00

Message:
Logged In: YES 
user_id=53855

Since you asked.

It is quite simple to upgrade the kernel, and I've been
doing it since 1996.  It's a bit more difficult to upgrade
libc's so I've stuck with what's working.

It's gotten to the point that I've been trying to see how long
I can go before I have to upgrade to libc6.  I'm hoping that
Python is portable enough that I don't have to upgrade my
libc to get it working (I didn't have to upgrade my libc to
get Perl running :-)

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

Comment By: Michael Hudson (mwh)
Date: 2004-01-22 11:03

Message:
Logged In: YES 
user_id=6656

You have a 2.4 kernel and are linking against libc *5*?!  Why?



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

Comment By: David Dyck (dcd)
Date: 2004-01-22 01:41

Message:
Logged In: YES 
user_id=53855

thank you for reminding me of the questions I should have
answered
uname -a
Linux dd 2.4.25-pre6 #1 Fri Jan 16 13:23:13 PST 2004 i686
gcc -v
Reading specs from
/usr/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.91.66.1/specs
gcc version egcs-2.91.66.1 19990314/Linux (egcs-1.1.2
release)

libc.so.5.4.44

dd:lib$ which python
/usr/local/bin/python
dd:lib$ python -V
Python 2.3.3
dd:lib$ ldd /usr/local/bin/python
        libpthread.so.0 => /lib/libpthread.so.0 (0x4000c000)
        libdl.so.1 => /lib/libdl.so.1 (0x4001d000)
        libm.so.5 => /lib/libm.so.5 (0x40020000)
        libc.so.5 => /lib/libc.so.5 (0x40029000)

(my perl installation doesn't link
with any threads - I've don't
think any application on this linux
system have used pthread either)



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

Comment By: Tim Peters (tim_one)
Date: 2004-01-22 01:18

Message:
Logged In: YES 
user_id=31435

Of course these tests pass on all the platforms the 
developers and testers used, else 2.3.3 wouldn't have been 
released.

So the most important bits of info are missing:  which OS, and 
which C compiler and runtime, and which thread 
implementation, are you using?

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

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

From noreply at sourceforge.net  Mon Feb  2 11:04:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb  2 11:04:42 2004
Subject: [ python-Bugs-889153 ] asyncore.dispactcher: incorrect connect
Message-ID: <E1AngYv-0005oF-00@sc8-sf-web1.sourceforge.net>

Bugs item #889153, was opened at 2004-02-02 16:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sankov Dmitry Alexandrovich (sankov_da)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore.dispactcher: incorrect connect

Initial Comment:
When i use non-blocking socket, connect() method of
asyncore.dispatcher class looks like works incorrect.

Example: if connection have not established then socket
merely closed and handle_error not called and no
exception throwed.

One more example: if writable() and readble() methods
returns zero than handle_connect() will never be called
even if connection will be established.

Thanks.


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

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

From noreply at sourceforge.net  Mon Feb  2 11:04:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb  2 11:04:58 2004
Subject: [ python-Bugs-889154 ] PyBool_* not documented in C API
Message-ID: <E1AngZE-0003yI-00@sc8-sf-web4.sourceforge.net>

Bugs item #889154, was opened at 2004-02-02 11:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889154&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyBool_* not documented in C API

Initial Comment:
The PyBool_* values and functions in the C API are not
documented; these should get a section in the "Concrete
Objects Layer" chapter.

Reported via email by Paul DuBois.

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

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

From noreply at sourceforge.net  Mon Feb  2 13:08:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb  2 13:08:57 2004
Subject: [ python-Bugs-889200 ] bundlebuilder standalone app doesn't fully
	quit
Message-ID: <E1AniV5-0004Nq-00@sc8-sf-web1.sourceforge.net>

Bugs item #889200, was opened at 2004-02-02 10:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder standalone app doesn't fully quit

Initial Comment:
I used bundlebuilder to create a fully standalone app (well, it fails on Jaguar, alas, but the python framework is inside the app). It works fine, but when I quit the app and try to delete it I get the following message from Finder and the item "python" in the .app is not deleted:

The operation cannot be completed because the item "Python" is in use.

The only way I've found to delete the app is to REBOOT. Simply logging out and in again does not do the job (which I find quite startling).

I worked around the problem by making the app semi_standalone, but would rather have it fully self-contained 

It's a huge app; I've not tried to break it down, but some things to consider:
- it uses networking (though I need not make a connection to cause this problem)
- it uses Tkinter (and yes the Tcl and Tk frameworks were installed in the app along with the Python framework)
- it uses a few threads for networking (again, though, the problem occurs even if no connection is ever made, suggesting that no threads have to be started to cause the problem)


-- Russell

I have attached the two code files I use to build the application (combined in one zip archive).

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

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

From noreply at sourceforge.net  Mon Feb  2 13:10:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb  2 13:10:30 2004
Subject: [ python-Bugs-889200 ] bundlebuilder standalone app doesn't fully
	quit
Message-ID: <E1AniWd-0007eu-00@sc8-sf-web2.sourceforge.net>

Bugs item #889200, was opened at 2004-02-02 10:08
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder standalone app doesn't fully quit

Initial Comment:
I used bundlebuilder to create a fully standalone app (well, it fails on Jaguar, alas, but the python framework is inside the app). It works fine, but when I quit the app and try to delete it I get the following message from Finder and the item "python" in the .app is not deleted:

The operation cannot be completed because the item "Python" is in use.

The only way I've found to delete the app is to REBOOT. Simply logging out and in again does not do the job (which I find quite startling).

I worked around the problem by making the app semi_standalone, but would rather have it fully self-contained 

It's a huge app; I've not tried to break it down, but some things to consider:
- it uses networking (though I need not make a connection to cause this problem)
- it uses Tkinter (and yes the Tcl and Tk frameworks were installed in the app along with the Python framework)
- it uses a few threads for networking (again, though, the problem occurs even if no connection is ever made, suggesting that no threads have to be started to cause the problem)


-- Russell

I have attached the two code files I use to build the application (combined in one zip archive).

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

>Comment By: Russell Owen (reowen)
Date: 2004-02-02 10:10

Message:
Logged In: YES 
user_id=431773

Note: the included BuildMacTUI.py uses semi_standalone = True, but the problem only occurs if I use standalone = True instead. Sorry for the potential confusion.

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

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

From noreply at sourceforge.net  Mon Feb  2 21:03:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb  2 21:03:26 2004
Subject: [ python-Bugs-887042 ] 2.3.3 str & list still use __getslice__ /
	__setslice__
Message-ID: <E1AnpuK-0003pi-00@sc8-sf-web3.sourceforge.net>

Bugs item #887042, was opened at 2004-01-29 10:47
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887042&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Florian B?sch (oodoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.3.3 str & list still use __getslice__ / __setslice__

Initial Comment:
Python 2.3.3 (#1, Jan 13 2004, 17:45:56)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2

str and list still use __getslice__ / __setslice__ for
the binary form

foo = mystr[1:2]
mystr[1:2] = foo

instead of __getitem__ / __setitem__ with slice objects.



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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-02 21:03

Message:
Logged In: YES 
user_id=593130

This only strikes me as a bug if use of *item is specified 
somewhere so that people subclassing builtin seqs know 
which methods to override.  Is it?  Are tuples different or just 
not checked?  

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

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

From noreply at sourceforge.net  Mon Feb  2 23:39:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb  2 23:39:40 2004
Subject: [ python-Bugs-889500 ] Line 0 SyntaxWarning with duplicate global
	declarations
Message-ID: <E1AnsLW-0000lC-00@sc8-sf-web3.sourceforge.net>

Bugs item #889500, was opened at 2004-02-02 20:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889500&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Connelly (jeffconnelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line 0 SyntaxWarning with duplicate global declarations

Initial Comment:
global a
a = "b"
global a

a.py:0: SyntaxWarning: name 'a' is assigned to before
global declaration


This is a fairly minor bug, however, the message is
misleading (the variable is in fact assigned to both
before and after the global declaration). At least, the
line number should be fixed to refer to the second
declaration, and if possible the error message should
be changed to "duplicate global declaration of 'a'".

P.S.: If "global a" is repeated multiple times, the
error message will be repeated, with the same line
number, and no indication that the warning refers to a
different line.



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

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

From noreply at sourceforge.net  Tue Feb  3 02:15:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb  3 02:16:00 2004
Subject: [ python-Feature Requests-889544 ] win32 raw socket support
Message-ID: <E1Anumo-0002YW-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #889544, was opened at 2004-02-03 08:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=889544&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jesko Huettenhain (jesko-rs)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32 raw socket support

Initial Comment:
I already programmed several tools in Windows that 
make use of raw sockets as Windows NT 5.0 and later 
OS (those include 2k and XP) support raw sockets in the 
Winsock 2 API. I used C/C++ for programming them 
mainly, but I figured python had the better builtin tools 
for building custom packets. However, I witnessed 
several problems when trying to create and use raw 
sockets in Python (Version 2.3, Windows interpreter): 
The raw socket was created, but the IP_HDRINCL 
option, for instance, could not be set once the socket 
was bound. This one and similar problems were indicating 
that the raw sockets implementation was either 
unavailable or had some strange bug.

After I had tried to find the problem in socketmodule.c 
for a while, I realized the problem was not the code, it 
was the library that had been linked with _socket.pyd. It 
looks like _socket.pyd links to wsock32.dll by default, 
which is the DLL that implements Winsock 1 for 32-bit 
windows. However, it should link to ws2_32.dll to provide 
access to the more up-to-date Winsock 2 API. The fix I 
suggest is fairly simple. The key is the WSAStartup() 
function which will let you use the Winsock2 API if it is 
available or use Winsock1 if Winsock2 is not available. 
For this purpose, I link using ws2_32.lib as recommended 
by MSDN and call WSAStartup() by requesting a Winsock 
Version of 2.0. MSDN says that if Winsock 2.0 is 
unavailable, the call will succeed and the Winsock 1 DLL 
will be used.

This fix works pretty well on my Windows 2k machine - I 
am unfortunately not able to test it on other machines 
as well. While messing with the problem, I got a lot of 
help from Matt Cowles [matt@mondoinfo.com] and he 
also suggested that I should post this request here, so 
that's what I am doing.

by_the_way:
As I was already messing with the _socket.pyd dll 
directly, I also added a new member function for python 
sockets called ioctl() to manually ioctl() the socket. 
Moreover, I added the integer constants IP_HDRINCL 
and SIO_RCVALL to be defined always, so that this code 
works and provides pretty satisfying results on my Win2k 
box (a simple sniffer):

from socket import *
s = socket(AF_INET,SOCK_RAW,IPPROTO_RAW)
s.bind((gethostbyname(gethostname()),0))
s.setsockopt(IPPROTO_IP,IP_HDRINCL,1)
s.ioctl(SIO_RCVALL,1)
while(1): print s.recvfrom(4000)[0],"\n------------"

The files I changed (including socket.py with the new 
ioctl function) can be found at:

http://rs.fromadia.com/pysockraw/

It would be very kind if the next version of the Python 
interpreter for windows would include this feature by 
default as it would allow developers like me to build 
python tools that make use of raw sockets in 
Windows ... I can see not many developers are 
interested in this particular feature, but more support is 
better than less support.


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

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

From noreply at sourceforge.net  Tue Feb  3 02:17:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb  3 02:17:57 2004
Subject: [ python-Feature Requests-889544 ] win32 raw socket support
Message-ID: <E1Anuoj-0002fN-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #889544, was opened at 2004-02-03 08:15
Message generated for change (Settings changed) made by jesko-rs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=889544&group_id=5470

Category: Windows
Group: None
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: Jesko Huettenhain (jesko-rs)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32 raw socket support

Initial Comment:
I already programmed several tools in Windows that 
make use of raw sockets as Windows NT 5.0 and later 
OS (those include 2k and XP) support raw sockets in the 
Winsock 2 API. I used C/C++ for programming them 
mainly, but I figured python had the better builtin tools 
for building custom packets. However, I witnessed 
several problems when trying to create and use raw 
sockets in Python (Version 2.3, Windows interpreter): 
The raw socket was created, but the IP_HDRINCL 
option, for instance, could not be set once the socket 
was bound. This one and similar problems were indicating 
that the raw sockets implementation was either 
unavailable or had some strange bug.

After I had tried to find the problem in socketmodule.c 
for a while, I realized the problem was not the code, it 
was the library that had been linked with _socket.pyd. It 
looks like _socket.pyd links to wsock32.dll by default, 
which is the DLL that implements Winsock 1 for 32-bit 
windows. However, it should link to ws2_32.dll to provide 
access to the more up-to-date Winsock 2 API. The fix I 
suggest is fairly simple. The key is the WSAStartup() 
function which will let you use the Winsock2 API if it is 
available or use Winsock1 if Winsock2 is not available. 
For this purpose, I link using ws2_32.lib as recommended 
by MSDN and call WSAStartup() by requesting a Winsock 
Version of 2.0. MSDN says that if Winsock 2.0 is 
unavailable, the call will succeed and the Winsock 1 DLL 
will be used.

This fix works pretty well on my Windows 2k machine - I 
am unfortunately not able to test it on other machines 
as well. While messing with the problem, I got a lot of 
help from Matt Cowles [matt@mondoinfo.com] and he 
also suggested that I should post this request here, so 
that's what I am doing.

by_the_way:
As I was already messing with the _socket.pyd dll 
directly, I also added a new member function for python 
sockets called ioctl() to manually ioctl() the socket. 
Moreover, I added the integer constants IP_HDRINCL 
and SIO_RCVALL to be defined always, so that this code 
works and provides pretty satisfying results on my Win2k 
box (a simple sniffer):

from socket import *
s = socket(AF_INET,SOCK_RAW,IPPROTO_RAW)
s.bind((gethostbyname(gethostname()),0))
s.setsockopt(IPPROTO_IP,IP_HDRINCL,1)
s.ioctl(SIO_RCVALL,1)
while(1): print s.recvfrom(4000)[0],"\n------------"

The files I changed (including socket.py with the new 
ioctl function) can be found at:

http://rs.fromadia.com/pysockraw/

It would be very kind if the next version of the Python 
interpreter for windows would include this feature by 
default as it would allow developers like me to build 
python tools that make use of raw sockets in 
Windows ... I can see not many developers are 
interested in this particular feature, but more support is 
better than less support.


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

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

From noreply at sourceforge.net  Tue Feb  3 16:04:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb  3 16:06:25 2004
Subject: [ python-Bugs-887042 ] 2.3.3 str & list still use __getslice__ /
	__setslice__
Message-ID: <E1Ao7j6-0005Yz-00@sc8-sf-web1.sourceforge.net>

Bugs item #887042, was opened at 2004-01-29 15:47
Message generated for change (Comment added) made by oodoo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887042&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Florian B?sch (oodoo)
Assigned to: Nobody/Anonymous (nobody)
>Summary: 2.3.3 str & list still use __getslice__ / __setslice__

Initial Comment:
Python 2.3.3 (#1, Jan 13 2004, 17:45:56)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2

str and list still use __getslice__ / __setslice__ for
the binary form

foo = mystr[1:2]
mystr[1:2] = foo

instead of __getitem__ / __setitem__ with slice objects.



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

>Comment By: Florian B?sch (oodoo)
Date: 2004-02-03 21:04

Message:
Logged In: YES 
user_id=723141

Jep, I noticed it while subclassing and overriding the
operators for slicing.
It's odd to deprecate a feature, and force the programmer to
use it anyway if he wants to sublcass existing types.

Is there an explicit typename for tuples? 

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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-03 02:03

Message:
Logged In: YES 
user_id=593130

This only strikes me as a bug if use of *item is specified 
somewhere so that people subclassing builtin seqs know 
which methods to override.  Is it?  Are tuples different or just 
not checked?  

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

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

From noreply at sourceforge.net  Tue Feb  3 17:25:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb  3 17:25:19 2004
Subject: [ python-Bugs-890010 ] Odd warning behaviors
Message-ID: <E1Ao8yh-0004in-00@sc8-sf-web2.sourceforge.net>

Bugs item #890010, was opened at 2004-02-03 17:25
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: Odd warning behaviors

Initial Comment:
This is from Evan Simpson, on the zope-dev list.  The 
bulk have to do with what happens if __name__ is set to 
None:


Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 
2.3.3 problem
http://mail.zope.org/mailman/listinfo/zope-dev

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> range(1.0)
__main__:1: DeprecationWarning: integer argument 
expected, got float
[0]
 >>>

So far, so good.  However:

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> __name__=None
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 63, in 
warn_explicit
     if module[-3:].lower() == ".py":
TypeError: unsubscriptable object
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import warnings
 >>> warnings.simplefilter("error", 
category=DeprecationWarning)
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 92, in 
warn_explicit
     raise message
DeprecationWarning: integer argument expected, got 
float
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import pdb
 >>> __name__ = None
 >>> pdb.run('range(1.0)')
 > <string>(1)?()
(Pdb) s
--Call--
 > /usr/lib/python2.3/warnings.py(24)warn()
-> def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning: 
tp_compare didn't return 
-1 or -2 for exception
   i = max(0, len(stack) - 1)
[traceback snipped]

Looks like something isn't properly propagating 
exceptions.

Cheers,

Evan @ 4-am


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

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

From noreply at sourceforge.net  Tue Feb  3 19:04:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb  3 19:04:32 2004
Subject: [ python-Bugs-890081 ] colorsys: bad URL
Message-ID: <E1AoAWp-0003XO-00@sc8-sf-web4.sourceforge.net>

Bugs item #890081, was opened at 2004-02-03 19:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890081&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David M. Cooke (dmcooke)
Assigned to: Nobody/Anonymous (nobody)
Summary: colorsys: bad URL

Initial Comment:
The URL given in the colorsys documentation (section
14.7 in the Python 2.3 Library Reference) for the color
FAQ now gives a 404. I believe this is it's new location:

http://www.poynton.com/ColorFAQ.html


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

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

From noreply at sourceforge.net  Wed Feb  4 07:10:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb  4 07:10:57 2004
Subject: [ python-Bugs-890010 ] Odd warning behaviors
Message-ID: <E1AoLro-0007Qk-00@sc8-sf-web1.sourceforge.net>

Bugs item #890010, was opened at 2004-02-03 22:25
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: Odd warning behaviors

Initial Comment:
This is from Evan Simpson, on the zope-dev list.  The 
bulk have to do with what happens if __name__ is set to 
None:


Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 
2.3.3 problem
http://mail.zope.org/mailman/listinfo/zope-dev

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> range(1.0)
__main__:1: DeprecationWarning: integer argument 
expected, got float
[0]
 >>>

So far, so good.  However:

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> __name__=None
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 63, in 
warn_explicit
     if module[-3:].lower() == ".py":
TypeError: unsubscriptable object
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import warnings
 >>> warnings.simplefilter("error", 
category=DeprecationWarning)
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 92, in 
warn_explicit
     raise message
DeprecationWarning: integer argument expected, got 
float
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import pdb
 >>> __name__ = None
 >>> pdb.run('range(1.0)')
 > <string>(1)?()
(Pdb) s
--Call--
 > /usr/lib/python2.3/warnings.py(24)warn()
-> def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning: 
tp_compare didn't return 
-1 or -2 for exception
   i = max(0, len(stack) - 1)
[traceback snipped]

Looks like something isn't properly propagating 
exceptions.

Cheers,

Evan @ 4-am


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

>Comment By: Michael Hudson (mwh)
Date: 2004-02-04 12:10

Message:
Logged In: YES 
user_id=6656

Might this be specific to range()?

[mwh@pc150 build]$ ./python.exe -Werror
Python 2.4a0 (#3, Feb  3 2004, 19:23:25) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> range(5.0)
[]

range()'s argument handling is somewhat odd

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

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

From noreply at sourceforge.net  Wed Feb  4 08:22:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb  4 08:22:28 2004
Subject: [ python-Bugs-890010 ] Odd warning behaviors
Message-ID: <E1AoMz1-0006gH-00@sc8-sf-web4.sourceforge.net>

Bugs item #890010, was opened at 2004-02-03 22:25
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: Odd warning behaviors

Initial Comment:
This is from Evan Simpson, on the zope-dev list.  The 
bulk have to do with what happens if __name__ is set to 
None:


Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 
2.3.3 problem
http://mail.zope.org/mailman/listinfo/zope-dev

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> range(1.0)
__main__:1: DeprecationWarning: integer argument 
expected, got float
[0]
 >>>

So far, so good.  However:

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> __name__=None
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 63, in 
warn_explicit
     if module[-3:].lower() == ".py":
TypeError: unsubscriptable object
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import warnings
 >>> warnings.simplefilter("error", 
category=DeprecationWarning)
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 92, in 
warn_explicit
     raise message
DeprecationWarning: integer argument expected, got 
float
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import pdb
 >>> __name__ = None
 >>> pdb.run('range(1.0)')
 > <string>(1)?()
(Pdb) s
--Call--
 > /usr/lib/python2.3/warnings.py(24)warn()
-> def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning: 
tp_compare didn't return 
-1 or -2 for exception
   i = max(0, len(stack) - 1)
[traceback snipped]

Looks like something isn't properly propagating 
exceptions.

Cheers,

Evan @ 4-am


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

>Comment By: Michael Hudson (mwh)
Date: 2004-02-04 13:22

Message:
Logged In: YES 
user_id=6656

OK, the problem is that returning NULL from 
getargs.c:convertsimple indicates *success* (argh!).

Fixing that provokes weird errors from handle_range_longs.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 12:10

Message:
Logged In: YES 
user_id=6656

Might this be specific to range()?

[mwh@pc150 build]$ ./python.exe -Werror
Python 2.4a0 (#3, Feb  3 2004, 19:23:25) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> range(5.0)
[]

range()'s argument handling is somewhat odd

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

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

From noreply at sourceforge.net  Wed Feb  4 10:03:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb  4 10:03:43 2004
Subject: [ python-Bugs-890010 ] Odd warning behaviors
Message-ID: <E1AoOYz-00046B-00@sc8-sf-web4.sourceforge.net>

Bugs item #890010, was opened at 2004-02-03 22:25
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: Odd warning behaviors

Initial Comment:
This is from Evan Simpson, on the zope-dev list.  The 
bulk have to do with what happens if __name__ is set to 
None:


Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 
2.3.3 problem
http://mail.zope.org/mailman/listinfo/zope-dev

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> range(1.0)
__main__:1: DeprecationWarning: integer argument 
expected, got float
[0]
 >>>

So far, so good.  However:

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> __name__=None
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 63, in 
warn_explicit
     if module[-3:].lower() == ".py":
TypeError: unsubscriptable object
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import warnings
 >>> warnings.simplefilter("error", 
category=DeprecationWarning)
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 92, in 
warn_explicit
     raise message
DeprecationWarning: integer argument expected, got 
float
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import pdb
 >>> __name__ = None
 >>> pdb.run('range(1.0)')
 > <string>(1)?()
(Pdb) s
--Call--
 > /usr/lib/python2.3/warnings.py(24)warn()
-> def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning: 
tp_compare didn't return 
-1 or -2 for exception
   i = max(0, len(stack) - 1)
[traceback snipped]

Looks like something isn't properly propagating 
exceptions.

Cheers,

Evan @ 4-am


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

>Comment By: Michael Hudson (mwh)
Date: 2004-02-04 15:03

Message:
Logged In: YES 
user_id=6656

How's this?  It's horrible, but I'm not sure that can be avoided.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 13:22

Message:
Logged In: YES 
user_id=6656

OK, the problem is that returning NULL from 
getargs.c:convertsimple indicates *success* (argh!).

Fixing that provokes weird errors from handle_range_longs.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 12:10

Message:
Logged In: YES 
user_id=6656

Might this be specific to range()?

[mwh@pc150 build]$ ./python.exe -Werror
Python 2.4a0 (#3, Feb  3 2004, 19:23:25) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> range(5.0)
[]

range()'s argument handling is somewhat odd

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

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

From noreply at sourceforge.net  Wed Feb  4 10:05:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb  4 10:05:50 2004
Subject: [ python-Bugs-890010 ] Odd warning behaviors
Message-ID: <E1AoOb1-0004Du-00@sc8-sf-web4.sourceforge.net>

Bugs item #890010, was opened at 2004-02-03 22:25
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: Odd warning behaviors

Initial Comment:
This is from Evan Simpson, on the zope-dev list.  The 
bulk have to do with what happens if __name__ is set to 
None:


Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 
2.3.3 problem
http://mail.zope.org/mailman/listinfo/zope-dev

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> range(1.0)
__main__:1: DeprecationWarning: integer argument 
expected, got float
[0]
 >>>

So far, so good.  However:

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> __name__=None
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 63, in 
warn_explicit
     if module[-3:].lower() == ".py":
TypeError: unsubscriptable object
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import warnings
 >>> warnings.simplefilter("error", 
category=DeprecationWarning)
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 92, in 
warn_explicit
     raise message
DeprecationWarning: integer argument expected, got 
float
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import pdb
 >>> __name__ = None
 >>> pdb.run('range(1.0)')
 > <string>(1)?()
(Pdb) s
--Call--
 > /usr/lib/python2.3/warnings.py(24)warn()
-> def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning: 
tp_compare didn't return 
-1 or -2 for exception
   i = max(0, len(stack) - 1)
[traceback snipped]

Looks like something isn't properly propagating 
exceptions.

Cheers,

Evan @ 4-am


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

>Comment By: Michael Hudson (mwh)
Date: 2004-02-04 15:05

Message:
Logged In: YES 
user_id=6656

Oops, wrong file.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 15:03

Message:
Logged In: YES 
user_id=6656

How's this?  It's horrible, but I'm not sure that can be avoided.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 13:22

Message:
Logged In: YES 
user_id=6656

OK, the problem is that returning NULL from 
getargs.c:convertsimple indicates *success* (argh!).

Fixing that provokes weird errors from handle_range_longs.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 12:10

Message:
Logged In: YES 
user_id=6656

Might this be specific to range()?

[mwh@pc150 build]$ ./python.exe -Werror
Python 2.4a0 (#3, Feb  3 2004, 19:23:25) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> range(5.0)
[]

range()'s argument handling is somewhat odd

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

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

From noreply at sourceforge.net  Wed Feb  4 14:44:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb  4 14:44:22 2004
Subject: [ python-Bugs-890687 ] upack fails under certain conditions on
	Windows
Message-ID: <E1AoSwb-0007Ze-00@sc8-sf-web1.sourceforge.net>

Bugs item #890687, was opened at 2004-02-04 19:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890687&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin (kneppy)
Assigned to: Thomas Heller (theller)
Summary: upack fails under certain conditions on Windows

Initial Comment:
When using unpack to decode and swap byte orders for 
a binary file that consists of a series of unsigned 
integers (big-endian 32bit format)  on a Windows 2000 
& XP machine,  a false result is returned for certain 
values.  The script failed reading the first value with the 
number 26 in big-endian format ('\x00\x00\x00\x1a') 
The same script and datafile worked fine using cygwin's 
version of python on the same machines, and also 
worked correctly on a Linux machine.  The attached files 
should be able to reproduce the behavior.

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

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

From noreply at sourceforge.net  Wed Feb  4 14:56:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb  4 14:56:56 2004
Subject: [ python-Bugs-890687 ] upack fails under certain conditions on
	Windows
Message-ID: <E1AoT8k-0005ED-00@sc8-sf-web4.sourceforge.net>

Bugs item #890687, was opened at 2004-02-04 20:44
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890687&group_id=5470

Category: Windows
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Kevin (kneppy)
Assigned to: Thomas Heller (theller)
Summary: upack fails under certain conditions on Windows

Initial Comment:
When using unpack to decode and swap byte orders for 
a binary file that consists of a series of unsigned 
integers (big-endian 32bit format)  on a Windows 2000 
& XP machine,  a false result is returned for certain 
values.  The script failed reading the first value with the 
number 26 in big-endian format ('\x00\x00\x00\x1a') 
The same script and datafile worked fine using cygwin's 
version of python on the same machines, and also 
worked correctly on a Linux machine.  The attached files 
should be able to reproduce the behavior.

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

>Comment By: Thomas Heller (theller)
Date: 2004-02-04 20:56

Message:
Logged In: YES 
user_id=11105

This is not a bug.  To read binary files on Windows, you
must open them with mode 'rb'.

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

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

From noreply at sourceforge.net  Wed Feb  4 15:04:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb  4 15:04:19 2004
Subject: [ python-Bugs-890687 ] upack fails under certain conditions on
	Windows
Message-ID: <E1AoTFr-0006Fo-00@sc8-sf-web3.sourceforge.net>

Bugs item #890687, was opened at 2004-02-04 14:44
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890687&group_id=5470

Category: Windows
>Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Kevin (kneppy)
Assigned to: Thomas Heller (theller)
Summary: upack fails under certain conditions on Windows

Initial Comment:
When using unpack to decode and swap byte orders for 
a binary file that consists of a series of unsigned 
integers (big-endian 32bit format)  on a Windows 2000 
& XP machine,  a false result is returned for certain 
values.  The script failed reading the first value with the 
number 26 in big-endian format ('\x00\x00\x00\x1a') 
The same script and datafile worked fine using cygwin's 
version of python on the same machines, and also 
worked correctly on a Linux machine.  The attached files 
should be able to reproduce the behavior.

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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-04 15:04

Message:
Logged In: YES 
user_id=31435

Change to Not-a-Bug.  Note that you *should* always open 
binary files in binary mode, regardless of platform.  On 
Windows you must do so (or suffer the consequences), but it 
doesn't hurt to do so on other platforms.

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

Comment By: Thomas Heller (theller)
Date: 2004-02-04 14:56

Message:
Logged In: YES 
user_id=11105

This is not a bug.  To read binary files on Windows, you
must open them with mode 'rb'.

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

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

From noreply at sourceforge.net  Wed Feb  4 15:19:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb  4 15:19:43 2004
Subject: [ python-Bugs-890705 ] upack produces incorrect result in certain
	circumstances 
Message-ID: <E1AoTUp-0006Xh-00@sc8-sf-web4.sourceforge.net>

Bugs item #890705, was opened at 2004-02-04 20:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890705&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin (kneppy)
Assigned to: Thomas Heller (theller)
Summary: upack produces incorrect result in certain circumstances 

Initial Comment:
When reading a binary datafile that consists of a series 
of unsigned integers (32 bit) in big-endian format and 
using unpack to read and convert the data to little 
endian, long unsigned integers, errors were noted on 
both Windows 2000 and Windows XP.  The data file 
(attached) produced errors on both Windows platforms 
when trying to read '26' in big-endian format, but the 
same operation would work on the command line.  The 
same script and datafile were used on the same 
machines using cygwin, (and the same version of 
Python: 2.3.3) and the results were correct.  The script 
and datafile also produced expected results on a Linux 
box.  The script and datafile that can reproduce the 
results are attached in a zip file.

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

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

From noreply at sourceforge.net  Wed Feb  4 15:21:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb  4 15:21:07 2004
Subject: [ python-Bugs-890705 ] unpack produces incorrect result in certain
	circumstances 
Message-ID: <E1AoTWA-0006Yk-00@sc8-sf-web4.sourceforge.net>

Bugs item #890705, was opened at 2004-02-04 20:19
Message generated for change (Settings changed) made by kneppy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890705&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin (kneppy)
Assigned to: Thomas Heller (theller)
>Summary: unpack produces incorrect result in certain circumstances 

Initial Comment:
When reading a binary datafile that consists of a series 
of unsigned integers (32 bit) in big-endian format and 
using unpack to read and convert the data to little 
endian, long unsigned integers, errors were noted on 
both Windows 2000 and Windows XP.  The data file 
(attached) produced errors on both Windows platforms 
when trying to read '26' in big-endian format, but the 
same operation would work on the command line.  The 
same script and datafile were used on the same 
machines using cygwin, (and the same version of 
Python: 2.3.3) and the results were correct.  The script 
and datafile also produced expected results on a Linux 
box.  The script and datafile that can reproduce the 
results are attached in a zip file.

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

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

From noreply at sourceforge.net  Wed Feb  4 15:41:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb  4 15:46:20 2004
Subject: [ python-Bugs-890705 ] unpack produces incorrect result in certain
	circumstances 
Message-ID: <E1AoTqM-00073R-00@sc8-sf-web2.sourceforge.net>

Bugs item #890705, was opened at 2004-02-04 21:19
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890705&group_id=5470

Category: Windows
>Group: Not a Bug
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Kevin (kneppy)
Assigned to: Thomas Heller (theller)
Summary: unpack produces incorrect result in certain circumstances 

Initial Comment:
When reading a binary datafile that consists of a series 
of unsigned integers (32 bit) in big-endian format and 
using unpack to read and convert the data to little 
endian, long unsigned integers, errors were noted on 
both Windows 2000 and Windows XP.  The data file 
(attached) produced errors on both Windows platforms 
when trying to read '26' in big-endian format, but the 
same operation would work on the command line.  The 
same script and datafile were used on the same 
machines using cygwin, (and the same version of 
Python: 2.3.3) and the results were correct.  The script 
and datafile also produced expected results on a Linux 
box.  The script and datafile that can reproduce the 
results are attached in a zip file.

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

>Comment By: Thomas Heller (theller)
Date: 2004-02-04 21:41

Message:
Logged In: YES 
user_id=11105

Have we been too quick?  Closed - this is a duplicate of 890687.

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

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

From noreply at sourceforge.net  Thu Feb  5 04:08:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb  5 04:09:07 2004
Subject: [ python-Bugs-890872 ] BSDDB set_location bug
Message-ID: <E1AofVL-0003nA-00@sc8-sf-web1.sourceforge.net>

Bugs item #890872, was opened at 2004-02-05 04:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890872&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Nobody/Anonymous (nobody)
Summary: BSDDB set_location bug

Initial Comment:
In module \lib\bsddb\__init__.py line 147, the method
set_location() uses self.dbc.set(key) , which raises an
error if the key is not found.  It should be using
self.dbc.set_range(key) , which matches the documented
behaviour for btree databases.

Test for correct behaviour is attached.

Behaviour is seen under Python 2.3.3 win32 binary build.

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

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

From noreply at sourceforge.net  Thu Feb  5 14:08:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb  5 14:08:45 2004
Subject: [ python-Bugs-891249 ] pickle dump argument description vague
Message-ID: <E1Aoorh-0003cg-00@sc8-sf-web2.sourceforge.net>

Bugs item #891249, was opened at 2004-02-05 19:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891249&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle dump argument description vague

Initial Comment:
The documentation for pickle.dump()

see http://www.python.org/doc/current/lib/node64.html

dump(  	object, file[, protocol[, bin]])

implies that up to four arguments can be specified.
That bin can be specified if protocol has been
specified. The implementation actually accepts only 3
arguments, the last one being either 'protocol' or a
'bin' flag.

The text notation for this function needs to be
clarified, and the visual presentation of the argument
functions changed.

Perhaps to:

dump(  	object, file[, protocol | bin])

or

dump(  	object, file[, protocol] | [, bin])

or

dump(  	object, file[, protocol_or_bin])




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

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

From noreply at sourceforge.net  Thu Feb  5 14:10:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb  5 14:11:53 2004
Subject: [ python-Bugs-891249 ] pickle dump argument description vague
Message-ID: <E1Aootu-0003lj-00@sc8-sf-web2.sourceforge.net>

Bugs item #891249, was opened at 2004-02-05 19:08
Message generated for change (Settings changed) made by bkc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891249&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Clements (bkc)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pickle dump argument description vague

Initial Comment:
The documentation for pickle.dump()

see http://www.python.org/doc/current/lib/node64.html

dump(  	object, file[, protocol[, bin]])

implies that up to four arguments can be specified.
That bin can be specified if protocol has been
specified. The implementation actually accepts only 3
arguments, the last one being either 'protocol' or a
'bin' flag.

The text notation for this function needs to be
clarified, and the visual presentation of the argument
functions changed.

Perhaps to:

dump(  	object, file[, protocol | bin])

or

dump(  	object, file[, protocol] | [, bin])

or

dump(  	object, file[, protocol_or_bin])




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

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

From noreply at sourceforge.net  Thu Feb  5 17:06:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb  5 17:07:00 2004
Subject: [ python-Bugs-891367 ] dict.get() evaluates second parameter even
	if key is present
Message-ID: <E1AoreC-0003Qx-00@sc8-sf-web3.sourceforge.net>

Bugs item #891367, was opened at 2004-02-05 23:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891367&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Claude Belisle (claude_belisle)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict.get() evaluates second parameter even if key is present

Initial Comment:
The optional parameter passed to get gets evaluated
even when the key is indeed present in the dictionary.
See attached file for the code I was using when
stumbling across this behaviour.

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

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

From noreply at sourceforge.net  Thu Feb  5 18:07:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb  5 18:07:28 2004
Subject: [ python-Bugs-891367 ] dict.get() evaluates second parameter even
	if key is present
Message-ID: <E1Aosag-0002xw-00@sc8-sf-web4.sourceforge.net>

Bugs item #891367, was opened at 2004-02-05 17:06
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891367&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Claude Belisle (claude_belisle)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict.get() evaluates second parameter even if key is present

Initial Comment:
The optional parameter passed to get gets evaluated
even when the key is indeed present in the dictionary.
See attached file for the code I was using when
stumbling across this behaviour.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-05 18:07

Message:
Logged In: YES 
user_id=80475

Unfortunately, that it is what it is supposed to do.

Workaround:

try:
    v = mydict[k]
except AttributeError:
    v = defaultmaker()



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

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

From noreply at sourceforge.net  Fri Feb  6 03:44:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb  6 03:44:29 2004
Subject: [ python-Bugs-891637 ] pydoc crashes on a class property
Message-ID: <E1Ap1b1-00058S-00@sc8-sf-web3.sourceforge.net>

Bugs item #891637, was opened at 2004-02-06 08:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891637&group_id=5470

Category: Demos and Tools
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc crashes on a class property

Initial Comment:
[forwarded from http://bugs.debian.org/231202]

---
class foo(object): 
    __slots__ = ['_bar'] 
    bar = property(lambda (self): self._bar) 
    def __init__(self, bar): self._bar = bar 
 
f = foo(1) 
assert(f.bar == 1) 
---

removing the parenthesis around the lambda's parameter 
avoids the pydoc crash. Python itself doesn't seem to
care about the parenthesis.

$ python tmp.py  # no errors
$ pydoc tmp 
Traceback (most recent call last): 
  File "/usr/bin/pydoc", line 4, in ? 
    pydoc.cli() 
  File "/usr/lib/python2.3/pydoc.py", line 2123, in cli 
    help.help(arg) 
  File "/usr/lib/python2.3/pydoc.py", line 1582, in help 
    elif request: doc(request, 'Help on %s:') 
  File "/usr/lib/python2.3/pydoc.py", line 1375, in doc 
    pager(title % desc + '\n\n' + text.document(object,
name)) 
  File "/usr/lib/python2.3/pydoc.py", line 283, in
document 
    if inspect.ismodule(object): return
self.docmodule(*args) 
  File "/usr/lib/python2.3/pydoc.py", line 990, in
docmodule 
    contents.append(self.document(value, key, name)) 
  File "/usr/lib/python2.3/pydoc.py", line 284, in
document 
    if inspect.isclass(object): return
self.docclass(*args) 
  File "/usr/lib/python2.3/pydoc.py", line 1135, in
docclass 
    lambda t: t[1] == 'property') 
  File "/usr/lib/python2.3/pydoc.py", line 1087, in
spillproperties 
    base = self.document(func, tag, mod) 
  File "/usr/lib/python2.3/pydoc.py", line 285, in
document 
    if inspect.isroutine(object): return
self.docroutine(*args) 
  File "/usr/lib/python2.3/pydoc.py", line 1177, in
docroutine 
    args, varargs, varkw, defaults =
inspect.getargspec(object) 
  File "/usr/lib/python2.3/inspect.py", line 656, in
getargspec 
    args, varargs, varkw = getargs(func.func_code) 
  File "/usr/lib/python2.3/inspect.py", line 624, in
getargs 
    remain[-1] = remain[-1] - 1 
IndexError: list index out of range 


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

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

From noreply at sourceforge.net  Fri Feb  6 09:57:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb  6 09:57:10 2004
Subject: [ python-Bugs-891832 ] commands module doesn't support background
	commands
Message-ID: <E1Ap7Pm-0002UT-00@sc8-sf-web2.sourceforge.net>

Bugs item #891832, was opened at 2004-02-06 08:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891832&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: commands module doesn't support background commands

Initial Comment:
The structure of the command passed to os.popen()
prevents the getoutput() and getstatusoutput() functions
from accepting commands for background
execution.  I think it would be sufficient to see if the
last non-whitespace character in the command was '&'
and if so, suppress insertion of the semicolon into the
command passed to os.popen():

  dosemi = not cmd.strip()[-1:] == '&'
  pipe = os.popen('{ %s%s } 2>&1' %
                         (cmd, dosemi and ';' or ''), 'r')

The above is untested, but based on my fiddling at the
shell prompt seems to be what's called for.

Since the status and output mean little or nothing
when the command is executed in the background,
perhaps a better alternative would be to add a new
function to the module which doesn't return either,
but dumps stdout and stderr to /dev/null.


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

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

From noreply at sourceforge.net  Fri Feb  6 11:54:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb  6 11:54:53 2004
Subject: [ python-Bugs-891930 ] configure argument --libdir is ignored
Message-ID: <E1Ap9Fg-0000SX-00@sc8-sf-web2.sourceforge.net>

Bugs item #891930, was opened at 2004-02-06 17:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891930&group_id=5470

Category: Build
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: G?ran Uddeborg (goeran)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure argument --libdir is ignored

Initial Comment:
I wanted to place the LIBDIR/python2.2 hierarchy on an
alternate place, so I tried giving the --libdir command
line option to configure.  The argument is accepted,
but apparently it is ignored during the build. 
Apparently, this directory is hard coded to be
PREFIX/lib/python2.2

You could argue if this is a bug report or an
enhancement request.  Since "configure --help" does
mention this option, I put it here.  In either case I
would consider it a good improvement to honour the
--libdir configure option.

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

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

From noreply at sourceforge.net  Fri Feb  6 18:17:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb  6 18:17:31 2004
Subject: [ python-Bugs-889200 ] bundlebuilder standalone app doesn't fully
	quit
Message-ID: <E1ApFDx-000092-00@sc8-sf-web4.sourceforge.net>

Bugs item #889200, was opened at 2004-02-02 19:08
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder standalone app doesn't fully quit

Initial Comment:
I used bundlebuilder to create a fully standalone app (well, it fails on Jaguar, alas, but the python framework is inside the app). It works fine, but when I quit the app and try to delete it I get the following message from Finder and the item "python" in the .app is not deleted:

The operation cannot be completed because the item "Python" is in use.

The only way I've found to delete the app is to REBOOT. Simply logging out and in again does not do the job (which I find quite startling).

I worked around the problem by making the app semi_standalone, but would rather have it fully self-contained 

It's a huge app; I've not tried to break it down, but some things to consider:
- it uses networking (though I need not make a connection to cause this problem)
- it uses Tkinter (and yes the Tcl and Tk frameworks were installed in the app along with the Python framework)
- it uses a few threads for networking (again, though, the problem occurs even if no connection is ever made, suggesting that no threads have to be started to cause the problem)


-- Russell

I have attached the two code files I use to build the application (combined in one zip archive).

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

>Comment By: Jack Jansen (jackjansen)
Date: 2004-02-07 00:17

Message:
Logged In: YES 
user_id=45365

Russell,
could you try using "ps" (probably "ps -x", both before running the .app 
and after running it) to check that the application has indeed fully exited? 
The fact that you mention there are multiple threads somehow suggests 
that there is something still using that Python...

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

Comment By: Russell Owen (reowen)
Date: 2004-02-02 19:10

Message:
Logged In: YES 
user_id=431773

Note: the included BuildMacTUI.py uses semi_standalone = True, but the problem only occurs if I use standalone = True instead. Sorry for the potential confusion.

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

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

From noreply at sourceforge.net  Sat Feb  7 13:03:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb  7 13:03:31 2004
Subject: [ python-Bugs-892492 ] Multiple close() for asyncore.dispatcher.
Message-ID: <E1ApWnf-0001xq-00@sc8-sf-web1.sourceforge.net>

Bugs item #892492, was opened at 2004-02-07 21:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892492&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexey Klimkin (klimkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple close() for asyncore.dispatcher.

Initial Comment:
dispatcher uses self._fileno to store socket's fd. 

    def del_channel(self, map=None):
        fd = self._fileno
        if map is None:
            map = socket_map
        if map.has_key(fd):
            #self.log_info('closing channel %d:%s' %
(fd, self))
            del map[fd]

calling close() for already closed channel will remove
new channels with same fileno.

The simple fix works perfect:

    def del_channel(self, map=None):
        if self._fileno is not None:
            fd = self._fileno
            if map is None:
                map = socket_map
            if map.has_key(fd):
                #self.log_info('closing channel %d:%s'
% (fd, self))
                del map[fd]
            self._fileno = None


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

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

From noreply at sourceforge.net  Sat Feb  7 21:15:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb  7 21:15:58 2004
Subject: [ python-Feature Requests-892707 ] debuggable/profileable Python
	framework
Message-ID: <E1ApeUE-0003d7-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #892707, was opened at 2004-02-07 21:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=892707&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: debuggable/profileable Python framework

Initial Comment:
It's standard procedure for frameworks on OS 
X is to have multiple binaries in the same framework 
for tasks such as debugging and profiling.  The developer would set 
the DYLD_IMAGE_SUFFIX environment variable in order to choose 
the non-standard image at runtime when they needed it.

It would rock if this could make it into the build scripts (so it would 
happen in OS X 10.4). I believe 
the only way right now is to configure+build three separate 
frameworks and stuff them all into one framework by hand.

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

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

From noreply at sourceforge.net  Sat Feb  7 21:15:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb  7 21:16:11 2004
Subject: [ python-Bugs-860134 ] socketmodule.c does not pickup all symbols
	with MS visC++
Message-ID: <E1ApeTe-0003br-00@sc8-sf-web4.sourceforge.net>

Bugs item #860134, was opened at 2003-12-14 18:27
Message generated for change (Comment added) made by jeffconnelly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860134&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Terhaar-Yonkers (frankty)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule.c does not pickup all symbols with MS visC++

Initial Comment:
The symbol: socket.IP_HDRINCL does not exist is the
Win32 Python binary I downloaded/installed of Python
v2.3, nor does it appear when I compile 2.3.3RC1 with
MS Visual C++.

If I add the following to socketmodule.c:
 (per the example in the windows SDK
./Samples/netds/WinSock/iphdrinc/rawudp.c)

#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN 
#endif
#include <winsock2.h>
#include <ws2tcpip.h>

All is well ..

I've no idea what symbol to #ifdef this on as this is
the first time I've compiled anything on "winders"  :-)
Any no idea if "lean_and_mean" is required - all I know
is that it now works ..

cheers,

- Frank
fty@employees.org


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

Comment By: Jeff Connelly (jeffconnelly)
Date: 2004-02-07 18:15

Message:
Logged In: YES 
user_id=31953

Defining WIN32_LEAN_AND_MEAN doesn't seem to work. The 
problem appears to be line 16 of socketmodule.h, which 
includes WinSock 2 #if _MSC_VER >= 1300 and WinSock 1 
otherwise. (IP_HDRINCL is a part of WinSock 2.) Apply this 
patch to use WinSock 2 on MS VC++ 6 (1200), which is what 
the Python Win32 builds are compiled with. (1300 is .Net?) 
pyconfig.h also needs to be patched.

socketmodule.h.patch:
17c17
< #if _MSC_VER >= 1300
---
> #if _MSC_VER >= 1200

pyconfig.h.patch:
327c327
< #if _MSC_VER + 0 >= 1300
---
> #if _MSC_VER + 0 >= 1200


With these patches, IP_HDRINCL exists in socket:

C:\>python
Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import socket
>>> socket.IP_HDRINCL
2
>>>



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

Comment By: Frank Terhaar-Yonkers (frankty)
Date: 2003-12-15 11:45

Message:
Logged In: YES 
user_id=931285

I have NO IDEA how it got assigned to you.  I don't even
know who you are ..

Sorry for any hassle.

cheers - Frank

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

Comment By: Thomas Heller (theller)
Date: 2003-12-15 08:27

Message:
Logged In: YES 
user_id=11105

Please don't assign bug reports to a developer (especially
not me ;-).
Usually they stay unassigned until someone cares (when he
has the time).

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

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

From noreply at sourceforge.net  Sat Feb  7 21:28:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb  7 21:28:59 2004
Subject: [ python-Bugs-860134 ] socketmodule.c does not pickup all symbols
	with MS visC++
Message-ID: <E1Apeg4-0001rB-00@sc8-sf-web3.sourceforge.net>

Bugs item #860134, was opened at 2003-12-14 18:27
Message generated for change (Comment added) made by jeffconnelly
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860134&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Terhaar-Yonkers (frankty)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule.c does not pickup all symbols with MS visC++

Initial Comment:
The symbol: socket.IP_HDRINCL does not exist is the
Win32 Python binary I downloaded/installed of Python
v2.3, nor does it appear when I compile 2.3.3RC1 with
MS Visual C++.

If I add the following to socketmodule.c:
 (per the example in the windows SDK
./Samples/netds/WinSock/iphdrinc/rawudp.c)

#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN 
#endif
#include <winsock2.h>
#include <ws2tcpip.h>

All is well ..

I've no idea what symbol to #ifdef this on as this is
the first time I've compiled anything on "winders"  :-)
Any no idea if "lean_and_mean" is required - all I know
is that it now works ..

cheers,

- Frank
fty@employees.org


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

Comment By: Jeff Connelly (jeffconnelly)
Date: 2004-02-07 18:28

Message:
Logged In: YES 
user_id=31953

P.S.: To get Winsock 2 working with Python, the _socket 
project must link with ws2_32.lib instead of wsock32.lib. 
Under VC++ 6 this can be done like this: Project -> Settings -
> highlight "_socket", Win32 release -> Link tab -> in 
the "Object/library modules" field change wsock32.lib to 
ws2_32.lib.


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

Comment By: Jeff Connelly (jeffconnelly)
Date: 2004-02-07 18:15

Message:
Logged In: YES 
user_id=31953

Defining WIN32_LEAN_AND_MEAN doesn't seem to work. The 
problem appears to be line 16 of socketmodule.h, which 
includes WinSock 2 #if _MSC_VER >= 1300 and WinSock 1 
otherwise. (IP_HDRINCL is a part of WinSock 2.) Apply this 
patch to use WinSock 2 on MS VC++ 6 (1200), which is what 
the Python Win32 builds are compiled with. (1300 is .Net?) 
pyconfig.h also needs to be patched.

socketmodule.h.patch:
17c17
< #if _MSC_VER >= 1300
---
> #if _MSC_VER >= 1200

pyconfig.h.patch:
327c327
< #if _MSC_VER + 0 >= 1300
---
> #if _MSC_VER + 0 >= 1200


With these patches, IP_HDRINCL exists in socket:

C:\>python
Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import socket
>>> socket.IP_HDRINCL
2
>>>



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

Comment By: Frank Terhaar-Yonkers (frankty)
Date: 2003-12-15 11:45

Message:
Logged In: YES 
user_id=931285

I have NO IDEA how it got assigned to you.  I don't even
know who you are ..

Sorry for any hassle.

cheers - Frank

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

Comment By: Thomas Heller (theller)
Date: 2003-12-15 08:27

Message:
Logged In: YES 
user_id=11105

Please don't assign bug reports to a developer (especially
not me ;-).
Usually they stay unassigned until someone cares (when he
has the time).

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

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

From noreply at sourceforge.net  Sun Feb  8 06:02:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 06:02:37 2004
Subject: [ python-Feature Requests-892804 ] Enumerate with step
Message-ID: <E1Apmhq-0007KY-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #892804, was opened at 2004-02-08 12:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=892804&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enumerate with step

Initial Comment:
I tried to do:

enumerate(letters)[::3]

...when I found out it didn't work. And it's different
from:

enumerate(letters[::3])

It would be nice if enumerate had a 'step' argument by
default, without subclassing it by hand.


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

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

From noreply at sourceforge.net  Sun Feb  8 06:16:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 06:17:06 2004
Subject: [ python-Feature Requests-892804 ] Enumerate with step
Message-ID: <E1Apmvp-0001LF-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #892804, was opened at 2004-02-08 06:02
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=892804&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enumerate with step

Initial Comment:
I tried to do:

enumerate(letters)[::3]

...when I found out it didn't work. And it's different
from:

enumerate(letters[::3])

It would be nice if enumerate had a 'step' argument by
default, without subclassing it by hand.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-08 06:16

Message:
Logged In: YES 
user_id=80475

Guido rejected the step argument to keep it separate from
slicing.

For a workaround, use itertools.islice():
    islice(enumerate('hello'),0,None,3)



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

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

From noreply at sourceforge.net  Sun Feb  8 06:36:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 06:37:05 2004
Subject: [ python-Bugs-892492 ] Multiple close() for asyncore.dispatcher.
Message-ID: <E1ApnFC-0000em-00@sc8-sf-web3.sourceforge.net>

Bugs item #892492, was opened at 2004-02-07 13:03
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892492&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Alexey Klimkin (klimkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple close() for asyncore.dispatcher.

Initial Comment:
dispatcher uses self._fileno to store socket's fd. 

    def del_channel(self, map=None):
        fd = self._fileno
        if map is None:
            map = socket_map
        if map.has_key(fd):
            #self.log_info('closing channel %d:%s' %
(fd, self))
            del map[fd]

calling close() for already closed channel will remove
new channels with same fileno.

The simple fix works perfect:

    def del_channel(self, map=None):
        if self._fileno is not None:
            fd = self._fileno
            if map is None:
                map = socket_map
            if map.has_key(fd):
                #self.log_info('closing channel %d:%s'
% (fd, self))
                del map[fd]
            self._fileno = None


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-08 06:36

Message:
Logged In: YES 
user_id=80475

Accepted and applied:  Lib/asyncore.py  1.44
Thanks for the contribution.




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

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

From noreply at sourceforge.net  Sun Feb  8 08:29:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 08:29:45 2004
Subject: [ python-Bugs-892854 ] typo in textwrap doc page
Message-ID: <E1App0I-0006Qp-00@sc8-sf-web2.sourceforge.net>

Bugs item #892854, was opened at 2004-02-08 04:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892854&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Drew Perttula (drewp)
Assigned to: Nobody/Anonymous (nobody)
Summary: typo in textwrap doc page

Initial Comment:
from
http://www.python.org/doc/current/lib/module-textwrap.html

dedent(text)
    Remove any whitespace than can be uniformly removed
from the left of every line in text.


^ 'than' looks like a typo for 'that'. 


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

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

From noreply at sourceforge.net  Sun Feb  8 10:55:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 10:56:02 2004
Subject: [ python-Bugs-892902 ] problem with pickling newstyle class
	instances
Message-ID: <E1AprHp-0004Kf-00@sc8-sf-web2.sourceforge.net>

Bugs item #892902, was opened at 2004-02-08 16:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892902&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Toon Verstraelen (tovrstra)
Assigned to: Nobody/Anonymous (nobody)
Summary: problem with pickling newstyle class instances

Initial Comment:
My python version:

Python 2.3.3 (#1, Jan 25 2004, 21:45:01)
[GCC 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3,
propolice)] on linux2

Please try the example. That will explain a lot. The
problem is that not all new style class instances are
picklable. In my example a class is derived from a list
and a base class. The list-descendant contains an
instance of the base class, which has a reference to
the list containing it. with cPickle things work fine,
but not for the normal pickle routines

class subitem:
	def __init__(self, parent):
		self.parent = parent
		if parent != None:
			parent.append(self)

class group(subitem, list):
	def __init__(self, parent):
		subitem.__init__(self, parent)
		

g = group(None)
s = subitem(g)

import cPickle
print cPickle.dumps(g)

import pickle
print pickle.dumps(g)

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

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

From noreply at sourceforge.net  Sun Feb  8 12:31:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 12:31:28 2004
Subject: [ python-Bugs-892939 ] Race condition in popen2
Message-ID: <E1ApsmB-0001gN-00@sc8-sf-web4.sourceforge.net>

Bugs item #892939, was opened at 2004-02-08 09:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892939&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ken McNeil (kenmcneil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Race condition in popen2

Initial Comment:
The "fix" for bug #761888 created a race condition in
Popen3  . The interaction between wait and _cleanup is
the root of the problem.

def wait(self):
  """Wait for and return the exit status of the child
process."""
  if self.sts < 0:
    pid, sts = os.waitpid(self.pid, 0)
    if pid == self.pid:
      self.sts = sts
  return self.sts

def _cleanup():
    for inst in _active[:]:
        inst.poll()

In wait, between the check of self.sts and the call to
os.waitpid a new Popen3 object can be created in
another thread which will trigger a call to _cleanup.
Since the call to _cleanup polls the process, when the
thread running wait starts back up again it will try to
poll the process using os.waitpid, which will throw an
OSError because os.waitpid has already been called for
the PID indirectly in _cleanup.

A work around is for the caller of wait to catch the
OSError and check the sts field, and if sts is
non-negative then the OSError is most likely because of
this problem and can be ignored. However, sts is
undocumented and should probably stay that way.

My suggestion is that the patch that added _active, 
_cleanup, and all  be removed and a more suitable
mechanism for fixing bug #761888 be found. As it has
been said in the discussion of bug #761888, magically
closing FDs is not a "good thing". It seems to me that
surrounding the call to os.fork with a try/except, and
closing the pipes in the except, would be suitable but
I don't know how this would interact with a failed call
to fork, therefore I wont provide a patch.

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

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

From noreply at sourceforge.net  Sun Feb  8 15:06:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 15:06:52 2004
Subject: [ python-Bugs-884020 ] opcode prediction distorts dynamic execution
	profile stats
Message-ID: <E1ApvCa-0000Bs-00@sc8-sf-web4.sourceforge.net>

Bugs item #884020, was opened at 2004-01-25 01:34
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=884020&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Raymond Hettinger (rhettinger)
Summary: opcode prediction distorts dynamic execution profile stats

Initial Comment:
By defining DYNAMIC_EXECUTION_PROFILE (and DXPAIRS if
you want opcode pair counts), opcode frequencies can be
evaluated for various program runs.

However successful opcode predictions bypass the
counter updates, which happen at the top of the loop.

So the result can be significantly under-represented
opcodes in the total statistics.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-08 15:06

Message:
Logged In: YES 
user_id=80475

Applied patch 884022.

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

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2004-01-25 01:47

Message:
Logged In: YES 
user_id=250749

See patch #884022 for a possible fix/work around.

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

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

From noreply at sourceforge.net  Sun Feb  8 15:10:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 15:10:33 2004
Subject: [ python-Bugs-892854 ] typo in textwrap doc page
Message-ID: <E1ApvG8-0000MD-00@sc8-sf-web4.sourceforge.net>

Bugs item #892854, was opened at 2004-02-08 08:29
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=892854&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Drew Perttula (drewp)
Assigned to: Nobody/Anonymous (nobody)
Summary: typo in textwrap doc page

Initial Comment:
from
http://www.python.org/doc/current/lib/module-textwrap.html

dedent(text)
    Remove any whitespace than can be uniformly removed
from the left of every line in text.


^ 'than' looks like a typo for 'that'. 


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-08 15:10

Message:
Logged In: YES 
user_id=80475

Fixed.  Thanks for the report.

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

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

From noreply at sourceforge.net  Sun Feb  8 22:12:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 22:12:07 2004
Subject: [ python-Bugs-542751 ] Config option --without-pth not working?
Message-ID: <E1Aq1q7-0000Ty-00@sc8-sf-web4.sourceforge.net>

Bugs item #542751, was opened at 2002-04-11 17:50
Message generated for change (Settings changed) made by blueronin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542751&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Mike Henderson (blueronin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Config option --without-pth not working?

Initial Comment:
Running "configure --with-threads --without-pth" seems 
to force libpth to be used. I would have expected it 
to force libpthread instead.

Using "configure --with-threads" causes libpthread to 
be used.

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

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

From noreply at sourceforge.net  Sun Feb  8 22:13:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 22:13:33 2004
Subject: [ python-Bugs-860547 ] Core dump problems
Message-ID: <E1Aq1rW-0006gG-00@sc8-sf-web3.sourceforge.net>

Bugs item #860547, was opened at 2003-12-15 15:06
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860547&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Draper (crunch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Core dump problems

Initial Comment:
Tried to install Python 2.3.3c1

 It keeps core dumping (leaving python.core). I'm not doing 
anything strange, just documented stuff from the manuals. 

  I tried 'gdb -c python.core' and then using 'back', but 
there are no labels compiled in (I hate that...); how can I
get the labels to be included? "./configure --debug" doesn't 
work. 

  I assume without the labels the numbers are 
meaningless. Running this under OpenBSD 3.2. Then, 
where should I submit my core dump (if anywhere?)?





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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-08 22:13

Message:
Logged In: YES 
user_id=80475

Do you still have install problems with the latest Python?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-15 18:12

Message:
Logged In: YES 
user_id=33168

try ./configure --with-pydebug
Do all the tests run?  (make test)

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

Comment By: John Draper (crunch)
Date: 2003-12-15 16:08

Message:
Logged In: YES 
user_id=61606

Further details on the Python core dump:

It core dumps (segmentation fault) when I check the database 
for a certain key. The offending statement is: 
x=database.has_key(keystring). database is open and otherwise 
normal.  The database is "gdbm-1.8.3". The offending key is 
"3012a3ec5c796329fee7c242d4df00d6".


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

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

From noreply at sourceforge.net  Sun Feb  8 22:15:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 22:15:23 2004
Subject: [ python-Bugs-842170 ] logging.shutdown() exception
Message-ID: <E1Aq1tD-0006kB-00@sc8-sf-web3.sourceforge.net>

Bugs item #842170, was opened at 2003-11-14 10:38
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842170&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: j vickroy (jvickroy)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging.shutdown() exception

Initial Comment:
Python version:
Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32

Operating System:
MS Windows 2000 Professional with all latest patches

Synopsis:

When reassigning a handler (RotatingFileSystem) to a 
logger during execution, close() must be invoked against 
the current handler.  Failure to do so causes the 
following exception to be raised:

 Traceback (most recent call last):
   File
 "C:\Python23\lib\site-
packages\Pythonwin\pywin\framework\scriptutils.py",
 line 310, in RunScript
     exec codeObject in __main__.__dict__
   File "E:\\experimental\Py Logging\t_xc.py", 
line 61, in ?
     log.error('testing Python logging module')
   File "C:\Python23\lib\logging\__init__.py", line 923, in 
error
     apply(self._log, (ERROR, msg, args), kwargs)
   File "C:\Python23\lib\logging\__init__.py", line 994, in 
_log
     self.handle(record)
   File "C:\Python23\lib\logging\__init__.py", line 1004, in 
handle
     self.callHandlers(record)
   File "C:\Python23\lib\logging\__init__.py", line 1037, in 
callHandlers
     hdlr.handle(record)
   File "C:\Python23\lib\logging\__init__.py", line 592, in 
handle
     self.emit(record)
   File "C:\Python23\lib\logging\handlers.py", line 105, in 
emit
     self.doRollover()
   File "C:\Python23\lib\logging\handlers.py", line 90, in 
doRollover
     os.rename(self.baseFilename, dfn)
 OSError: [Errno 13] Permission denied

If close() is applied to each handler, except the final 
assigned handler, then logging.shutdown() raises the 
following exception when it is applied prior to application 
termination:

Traceback (most recent call last):
  File "D:\\experimental\Py Logging\t_xb.py", 
line 63, in ?
    shutdown()
  File "C:\Python23\lib\logging\__init__.py", line 1195, in 
shutdown
    h.flush()
  File "C:\Python23\lib\logging\__init__.py", line 661, in 
flush
    self.stream.flush()
ValueError: I/O operation on closed file

apparently, because it is attempting to close previously-
closed handlers.

Please, see attachment for a relevant script.

If it is agreed that this is an appropriate use of the 
logging system (and I think it is <smile>), I would be 
willing to attempt a patch if that is preferable.

Thanks for your time.

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

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

From noreply at sourceforge.net  Sun Feb  8 22:16:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 22:16:10 2004
Subject: [ python-Bugs-878458 ] optparse help text is not easily extensible
Message-ID: <E1Aq1u1-0006m2-00@sc8-sf-web3.sourceforge.net>

Bugs item #878458, was opened at 2004-01-16 13:59
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878458&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Bicking (ianbicking)
>Assigned to: Greg Ward (gward)
Summary: optparse help text is not easily extensible

Initial Comment:
optparse doesn't allow for paragraph/narrative help
text.  This text would typically go below the option
listing.

There is currently no place to describe positional
arguments, and this would be a simple way to allow for
that.  This could be provided as an extra keyword
argument to OptionParser.__init__, included in the help
in the function OptionParser.format_help.

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

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

From noreply at sourceforge.net  Sun Feb  8 22:17:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 22:17:17 2004
Subject: [ python-Bugs-878453 ] optparse indents without respect to $COLUMNS
Message-ID: <E1Aq1v5-0006oe-00@sc8-sf-web3.sourceforge.net>

Bugs item #878453, was opened at 2004-01-16 13:50
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878453&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Bicking (ianbicking)
>Assigned to: Greg Ward (gward)
Summary: optparse indents without respect to $COLUMNS

Initial Comment:
optparse should pay attention to the $COLUMNS
environmental variable if it is available. 
optparse.IndentedHelpFormatter.__init__ should take
None as the default for width, and do something like:

if width is None: width = os.environ.get('COLUMNS', 80)

Better if it's put in HelpFormatter, so that
IndentedHelpFormatter and TitledHelpFormatter both act
the same.

(Python 2.3.3, FreeBSD)


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

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

From noreply at sourceforge.net  Sun Feb  8 22:25:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb  8 22:25:46 2004
Subject: [ python-Bugs-823209 ] cmath.log doesn't have the same interface as
	math.log.
Message-ID: <E1Aq239-0007CO-00@sc8-sf-web3.sourceforge.net>

Bugs item #823209, was opened at 2003-10-13 23:23
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823209&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: cmath.log doesn't have the same interface as math.log.

Initial Comment:
Somewhere along the way, math.log gained an optional
"base" argument.  cmath.log is still missing it.

>>> print math.log.__doc__
log(x[, base]) -> the logarithm of x to the given base.
If the base not specified, returns the natural
logarithm (base e) of x.

>>> print cmath.log.__doc__
log(x)

Return the natural logarithm of x.

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

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-10-27 17:03

Message:
Logged In: YES 
user_id=99508

In my particular usecase, I define an environment in which
people can execute mathematical statements like so:

_mathEnv = {'__builtins__': new.module('__builtins__'), 'i': 1j}
_mathEnv.update(math.__dict__)
_mathEnv.update(cmath.__dict__)

As you can see, the cmath definitions shadow the math
definitions, and thus I lose the useful ability to offer
users a log with a base (which those that know Python expect
to work).

That's at least my particular use case.  In this particular
instance, since I don't want to allow the users to cause the
application to consume arbitrary amounts of memory, I can't
allow integer arithmetic (because of the crazy int/long
unification that left people who wanted computationall
bounded arithmetic with no choice but to implement a
fixed-size integer type or use float/complex instead ;)) so
I use complex objects everywhere, and math.log can't operate
on complex objects (even those that have no imaginary
component).

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

Comment By: Andrew Gaul (gaul)
Date: 2003-10-27 15:20

Message:
Logged In: YES 
user_id=139865

Base 2 logarithms are somewhat common.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-10-27 14:44

Message:
Logged In: YES 
user_id=80475

I can fix this if necessary.

My question is whether it should be done.  On the one hand,
it is nice to have the two interfaces as symmetrical as
possible.  OTOH,  I'm not aware of any use cases for log(z, b).



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

Comment By: Andrew Gaul (gaul)
Date: 2003-10-18 13:42

Message:
Logged In: YES 
user_id=139865

See patch #826074 for a fix.

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

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

From noreply at sourceforge.net  Mon Feb  9 02:11:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb  9 02:11:17 2004
Subject: [ python-Bugs-893250 ] curses getkey() crash in raw mode
Message-ID: <E1Aq5ZZ-00016i-00@sc8-sf-web1.sourceforge.net>

Bugs item #893250, was opened at 2004-02-09 01:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893250&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: J. David Lee (bogjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses getkey() crash in raw mode

Initial Comment:
Using python 2.3.3 on gentoo I have the following problem:

When calling stdscr.getkey() in raw mode, the program
crashes on a terminal resize event. In cooked and
cbreak modes, the proper string is returned -
"KEY_RESIZE". This problem appeared after upgrading
from python 2.3.2, I believe. Below is a quick program
that exhibits this behavior on my machine.

#######################################################
#!/usr/bin/env python

import curses;

stdscr = curses.initscr();
curses.raw();
curses.noecho();
stdscr.keypad(1);

while(1):
  stdscr.clear();
  stdscr.addstr("Enter key: ");
  c = stdscr.getkey();
  if(c == 'q'):
    break;
  stdscr.clear();
  stdscr.addstr('"' + c + '"\n\n');
  stdscr.addstr("Press any key...");
  stdscr.getkey();

curses.noraw();
curses.endwin();
#######################################################

A couple of other notes: 
1) No exception is thrown (a try block doesn't catch it).
2) The behavior is the same using the interactive
interpreter.
3) The traceback is: File "./keyname", line 19, in ?
stdscr.getkey(); _curses.error: no input


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

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

From noreply at sourceforge.net  Mon Feb  9 12:30:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb  9 12:30:55 2004
Subject: [ python-Bugs-893549 ] skipitem() in getargs.c missing some types
Message-ID: <E1AqFFE-000075-00@sc8-sf-web4.sourceforge.net>

Bugs item #893549, was opened at 2004-02-09 17:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893549&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kirill A Kryloff (hacocuk)
Assigned to: Nobody/Anonymous (nobody)
Summary: skipitem() in getargs.c missing some types

Initial Comment:
python 2.2.3
looks like skipitem in getargs.c is missing some types
'k' for example


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

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

From noreply at sourceforge.net  Mon Feb  9 13:46:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb  9 13:46:44 2004
Subject: [ python-Bugs-893610 ] Segmentation fault running XSV
Message-ID: <E1AqGQZ-0007mg-00@sc8-sf-web3.sourceforge.net>

Bugs item #893610, was opened at 2004-02-09 19:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893610&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean-Baptiste Combes (jbcombes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault running XSV

Initial Comment:
Python 2.3.* segfaults while running XSV. Python 2.2 is OK
I have no clue about what may be the problem.
Here is a backtrace by GDB :

(gdb) run commandLine.py

[New Thread 1024 (LWP 29583)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 29583)]
__pthread_mutex_lock (mutex=0x475) at mutex.c:99
99      mutex.c: No such file or directory.
        in mutex.c
(gdb) bt
#0  __pthread_mutex_lock (mutex=0x475) at mutex.c:99
#1  0x400e2be8 in __libc_free (mem=0x4029d528) at
malloc.c:3152
#2  0x402f0dcf in Item_Dealloc (self=0x4029d528) at
NSLintermodule.c:2641
#3  0x080a7092 in call_function (pp_stack=0xbfffea2c,
oparg=2)
    at Python/ceval.c:3467
#4  0x080a5667 in eval_frame (f=0x818a42c) at
Python/ceval.c:2116
#5  0x080a65f3 in PyEval_EvalCodeEx (co=0x402b6720,
globals=0x40273714, 
    locals=0x0, args=0x81e69d8, argcount=2,
kws=0x81e69e0, kwcount=0, 
    defs=0x403b5a38, defcount=1, closure=0x0) at
Python/ceval.c:2663
#6  0x080a8adb in fast_function (func=0x4025ef7c,
pp_stack=0xbfffebcc, n=2, 
    na=2, nk=0) at Python/ceval.c:3532
#7  0x080a7036 in call_function (pp_stack=0xbfffebcc,
oparg=2)
    at Python/ceval.c:3458
#8  0x080a5667 in eval_frame (f=0x81e6874) at
Python/ceval.c:2116
#9  0x080a8a77 in fast_function (func=0x4025ef0c,
pp_stack=0xbfffecdc, n=2, 
    na=2, nk=0) at Python/ceval.c:3518
#10 0x080a7036 in call_function (pp_stack=0xbfffecdc,
oparg=2)
    at Python/ceval.c:3458
#11 0x080a5667 in eval_frame (f=0x816c6d4) at
Python/ceval.c:2116
#12 0x080a8a77 in fast_function (func=0x402afe64,
pp_stack=0xbfffedec, n=2, 
    na=2, nk=0) at Python/ceval.c:3518
#13 0x080a7036 in call_function (pp_stack=0xbfffedec,
oparg=1)
    at Python/ceval.c:3458
---Type <return> to continue, or q <return> to quit---
#14 0x080a5667 in eval_frame (f=0x81bc834) at
Python/ceval.c:2116
#15 0x080a65f3 in PyEval_EvalCodeEx (co=0x402641a0,
globals=0x4027335c, 
    locals=0x0, args=0x40345b00, argcount=3, kws=0x0,
kwcount=0, 
    defs=0x402b2db8, defcount=2, closure=0x0) at
Python/ceval.c:2663
#16 0x080e3def in function_call (func=0x402afe2c,
arg=0x40345af4, kw=0x0)
    at Objects/funcobject.c:504
#17 0x0805a004 in PyObject_Call (func=0x402afe2c,
arg=0x40345af4, kw=0x0)
    at Objects/abstract.c:1755
#18 0x08060cc3 in instancemethod_call (func=0x402afe2c,
arg=0x4020d2ec, kw=0x0)
    at Objects/classobject.c:2433
#19 0x0805a004 in PyObject_Call (func=0x403c6c84,
arg=0x4020d2ec, kw=0x0)
    at Objects/abstract.c:1755
#20 0x080a82ab in PyEval_CallObjectWithKeywords
(func=0x403c6c84, 
    arg=0x4020d2ec, kw=0x0) at Python/ceval.c:3346
#21 0x0805cd5f in PyInstance_New (klass=0x402c2b6c,
arg=0x4020d2ec, kw=0x0)
    at Objects/classobject.c:575
#22 0x0805a004 in PyObject_Call (func=0x402c2b6c,
arg=0x4020d2ec, kw=0x0)
    at Objects/abstract.c:1755
#23 0x080a8b66 in do_call (func=0x402c2b6c,
pp_stack=0xbffff2cc, na=2, nk=0)
    at Python/ceval.c:3644
#24 0x080a704d in call_function (pp_stack=0xbffff2cc,
oparg=2)
    at Python/ceval.c:3460
#25 0x080a5667 in eval_frame (f=0x814867c) at
Python/ceval.c:2116
---Type <return> to continue, or q <return> to quit---
#26 0x080a65f3 in PyEval_EvalCodeEx (co=0x40206520,
globals=0x401feb54, 
    locals=0x0, args=0x8159db0, argcount=12,
kws=0x8159de0, kwcount=0, 
    defs=0x40277620, defcount=11, closure=0x0) at
Python/ceval.c:2663
#27 0x080a8adb in fast_function (func=0x40347144,
pp_stack=0xbffff46c, n=12, 
    na=12, nk=0) at Python/ceval.c:3532
#28 0x080a7036 in call_function (pp_stack=0xbffff46c,
oparg=12)
    at Python/ceval.c:3458
#29 0x080a5667 in eval_frame (f=0x8159c04) at
Python/ceval.c:2116
#30 0x080a65f3 in PyEval_EvalCodeEx (co=0x402062e0,
globals=0x401feb54, 
    locals=0x0, args=0x819303c, argcount=15,
kws=0x8193078, kwcount=0, 
    defs=0x4026c628, defcount=14, closure=0x0) at
Python/ceval.c:2663
#31 0x080a8adb in fast_function (func=0x4034709c,
pp_stack=0xbffff60c, n=15, 
    na=15, nk=0) at Python/ceval.c:3532
#32 0x080a7036 in call_function (pp_stack=0xbffff60c,
oparg=15)
    at Python/ceval.c:3458
#33 0x080a5667 in eval_frame (f=0x8192ea4) at
Python/ceval.c:2116
#34 0x080a8a77 in fast_function (func=0x40202c34,
pp_stack=0xbffff71c, n=1, 
    na=1, nk=0) at Python/ceval.c:3518
#35 0x080a7036 in call_function (pp_stack=0xbffff71c,
oparg=1)
    at Python/ceval.c:3458
#36 0x080a5667 in eval_frame (f=0x812444c) at
Python/ceval.c:2116
#37 0x080a65f3 in PyEval_EvalCodeEx (co=0x401ff2e0,
globals=0x401b879c, 
    locals=0x401b879c, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, closure=0x0) at Python/ceval.c:2663
#38 0x080a8976 in PyEval_EvalCode (co=0x401ff2e0,
globals=0x401b879c, 
    locals=0x401b879c) at Python/ceval.c:542
#39 0x080c4db1 in run_node (n=0x4019f488, 
    filename=0xbffffa73 "commandLine.py",
globals=0x401b879c, locals=0x401b879c, 
    flags=0xbffff89c) at Python/pythonrun.c:1265
#40 0x080c3781 in PyRun_SimpleFileExFlags (fp=0x8122288, 
    filename=0xbffffa73 "commandLine.py", closeit=1,
flags=0xbffff89c)
    at Python/pythonrun.c:862
#41 0x0805506a in Py_Main (argc=2, argv=0xbffff934) at
Modules/main.c:415
#42 0x4007e507 in __libc_start_main (main=0x8054980
<main>, argc=2, 
    ubp_av=0xbffff934, init=0x8053cb0 <_init>,
fini=0x80e6ae0 <_fini>, 
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff92c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) 


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

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

From noreply at sourceforge.net  Mon Feb  9 20:18:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb  9 20:18:34 2004
Subject: [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E1AqMXf-0007Xo-00@sc8-sf-web1.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 03:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 3
Submitted By: Matthias Klose (doko)
>Assigned to: Brett Cannon (bcannon)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-02-09 17:18

Message:
Logged In: YES 
user_id=357491

After staring at the code, I am not even sure if the calls for its side-
effect are needed.  If you call currentThread(), it either returns a value 
from _active which is a dict of running Thread instances indexed by 
thread idents, or a new _DummyThread instance that inserts itself into 
_active.  Now the two calls in the _Condition class are purely for this 
possible side-effect.

And yet at no point is anything from _active, through currentThread or 
direct access, even touched by a _Condition method.  The only chance 
this might be an issue is if a _Condition instance uses an RLock instance 
for its locking, which is the default behavior.

But this still makes the side-effect need useless.  RLocks will call 
currentThread on their own and since this is all in the same thread the 
result won't change.  And in this specific case of this bug, the _Condition 
instance is created with a Lock instance since that is what the Thread 
instance uses for constructing the _Condition instance it use, which is just 
thread.allocate_lock() which is obviously not an RLock.

In other words I can't find the point to the side-effect in _Condition.  I 
will try to come up with some testing code that reproduces the error and 
then see if just removing the calls in _Condition remove the error and 
still pass the regression tests.

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

Comment By: John Goerzen (jgoerzen)
Date: 2003-06-16 06:26

Message:
Logged In: YES 
user_id=491567

I can confirm that this behavior is not present in Python 2.2 in 
the same version that I am using to test against Python 2.3. 
 
I will be on vacation for most of this and next week.  I'll try to 
get to the logging script before I leave, but I might not get to it 
until I return. 
 
FYI, you can also obtain OfflineIMAP at 
http://quux.org/devel/offlineimap. 
 
 

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:58

Message:
Logged In: YES 
user_id=357491

OK, following Tim's advice I checked and it seems that Thread 
calls a method while shutting itself down that calls 
Condition.notifyAll which calls currentThread which is a global.  It 
would appear that offlineimap is leaving its threads running, the 
program gets shut down, the threads raise an error while 
shutting down (probably because things are being torn down), 
this triggers the stopping method in Thread, and this raises its 
own exception because of the teardown which is what we are 
seeing as the TypeError.

So the question is whether Condition should store a local 
reference to currentThread or not.  It is not the most pure 
solution since this shutdown issue is not Condition's, but the only 
other solution I can think of is to have Thread keep a reference 
to currentThread, inject it into the current frame's global 
namespace, call Condition.notifyAll, and then remove the 
reference from the frame again.  I vote for the cleaner, less pure 
solution.  =)

Am I insane on this or does it at least sound like this is the 
problem and proper solution?

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:19

Message:
Logged In: YES 
user_id=357491

Nuts.  For some reason I thought the OP had said when threads 
were exiting.

I will ask on python-dev for a good explanation of what happens 
when Python is shutting down.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-15 18:05

Message:
Logged In: YES 
user_id=31435

Note that the OP said "when my application exits".  When 
Python is tearing down the universe, it systematically sets 
module-global bindings to None.  currentThread() is a module 
global.  I can't make more time for this now, so for more info 
talk about it on Python-Dev.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 16:44

Message:
Logged In: YES 
user_id=357491

Well, I'm stumped.  I checked the diff from when 2.2 was initially 
released until now and the only change that seems to be related 
to any of this is that what is returned by currentThread is not 
saved in a variable.  But since the error is the calling of 
currentThread itself and not saving the return value I don't see 
how that would affect anything.

I also went through offlineimap but I didn't see anything there 
that seemed to be setting currentThread to None.  Although 
since several files do ``import *`` so there still is a possibility of 
overwriting currentThread locally.

So, for my owning learning and to help solve this, I have written 
a tracing function that writes to stderr using the logging package 
when it detects that either currentThread or 
threading.currentThread has been set to None, locally or globally 
(I assume the code is not injecting into builtins so I didn't bother 
checking there).  The file is named tracer.py and I have attached 
it to this bug report.  If you can execute 
``sys.settrace(tracer.trace_currentThread)`` before offlinemap 
starts executing and immediately within each thread (it has to be 
called in *every* thread since tracing functions are no inherited 
from the main thread) it should print out a message when 
currentThread becomes None.  If you *really* want to make this 
robust you can also have it check sys.modules['threading'] every 
time as well, but I figure there is not going to be much renaming 
and masking of currentThread.

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

Comment By: Matthias Klose (doko)
Date: 2003-06-15 01:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 01:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

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

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

From noreply at sourceforge.net  Mon Feb  9 20:22:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb  9 20:22:38 2004
Subject: [ python-Bugs-890081 ] colorsys: bad URL
Message-ID: <E1AqMbi-0005lL-00@sc8-sf-web4.sourceforge.net>

Bugs item #890081, was opened at 2004-02-03 16:04
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890081&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David M. Cooke (dmcooke)
Assigned to: Nobody/Anonymous (nobody)
Summary: colorsys: bad URL

Initial Comment:
The URL given in the colorsys documentation (section
14.7 in the Python 2.3 Library Reference) for the color
FAQ now gives a 404. I believe this is it's new location:

http://www.poynton.com/ColorFAQ.html


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-02-09 17:22

Message:
Logged In: YES 
user_id=357491

Thanks for noticing.  It was fixed in 2.4 but it didn't get backported.  Now 
fixed as rev. 1.1.48.1 on Doc/lib/libcolorsys.text .

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

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

From noreply at sourceforge.net  Tue Feb 10 13:11:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 10 13:30:31 2004
Subject: [ python-Bugs-894428 ] - very minor typo
Message-ID: <E1AqcMQ-00012H-00@sc8-sf-web3.sourceforge.net>

Bugs item #894428, was opened at 2004-02-10 11:07
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=894428&group_id=5470

Category: Documentation
Group: Not a Bug
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Nikolay Diakov (diakov)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: - very minor typo

Initial Comment:
currently I read the 
"5.3 Pure Embedding"
from the online documentation at Python.org
In the first paragraph the second sentence contains
" (but that will change in th next section)."
where I believe someone has missed an 'e' after the 
"th".

Keep up the good work.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-02-10 13:11

Message:
Logged In: YES 
user_id=33168

Thanks!  Checked in as Doc/ext/embedding.tex 1.9 and 1.8.16.1

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

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

From noreply at sourceforge.net  Tue Feb 10 11:07:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 10 15:25:40 2004
Subject: [ python-Bugs-894428 ] - very minor typo
Message-ID: <E1AqaPi-0004Hx-00@sc8-sf-web4.sourceforge.net>

Bugs item #894428, was opened at 2004-02-10 17:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=894428&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Nikolay Diakov (diakov)
Assigned to: Nobody/Anonymous (nobody)
Summary: - very minor typo

Initial Comment:
currently I read the 
"5.3 Pure Embedding"
from the online documentation at Python.org
In the first paragraph the second sentence contains
" (but that will change in th next section)."
where I believe someone has missed an 'e' after the 
"th".

Keep up the good work.

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

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

From noreply at sourceforge.net  Tue Feb 10 04:25:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 10 15:26:10 2004
Subject: [ python-Bugs-893610 ] Segmentation fault running XSV
Message-ID: <E1AqU9V-0001Vy-00@sc8-sf-web2.sourceforge.net>

Bugs item #893610, was opened at 2004-02-09 19:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893610&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean-Baptiste Combes (jbcombes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault running XSV

Initial Comment:
Python 2.3.* segfaults while running XSV. Python 2.2 is OK
I have no clue about what may be the problem.
Here is a backtrace by GDB :

(gdb) run commandLine.py

[New Thread 1024 (LWP 29583)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 29583)]
__pthread_mutex_lock (mutex=0x475) at mutex.c:99
99      mutex.c: No such file or directory.
        in mutex.c
(gdb) bt
#0  __pthread_mutex_lock (mutex=0x475) at mutex.c:99
#1  0x400e2be8 in __libc_free (mem=0x4029d528) at
malloc.c:3152
#2  0x402f0dcf in Item_Dealloc (self=0x4029d528) at
NSLintermodule.c:2641
#3  0x080a7092 in call_function (pp_stack=0xbfffea2c,
oparg=2)
    at Python/ceval.c:3467
#4  0x080a5667 in eval_frame (f=0x818a42c) at
Python/ceval.c:2116
#5  0x080a65f3 in PyEval_EvalCodeEx (co=0x402b6720,
globals=0x40273714, 
    locals=0x0, args=0x81e69d8, argcount=2,
kws=0x81e69e0, kwcount=0, 
    defs=0x403b5a38, defcount=1, closure=0x0) at
Python/ceval.c:2663
#6  0x080a8adb in fast_function (func=0x4025ef7c,
pp_stack=0xbfffebcc, n=2, 
    na=2, nk=0) at Python/ceval.c:3532
#7  0x080a7036 in call_function (pp_stack=0xbfffebcc,
oparg=2)
    at Python/ceval.c:3458
#8  0x080a5667 in eval_frame (f=0x81e6874) at
Python/ceval.c:2116
#9  0x080a8a77 in fast_function (func=0x4025ef0c,
pp_stack=0xbfffecdc, n=2, 
    na=2, nk=0) at Python/ceval.c:3518
#10 0x080a7036 in call_function (pp_stack=0xbfffecdc,
oparg=2)
    at Python/ceval.c:3458
#11 0x080a5667 in eval_frame (f=0x816c6d4) at
Python/ceval.c:2116
#12 0x080a8a77 in fast_function (func=0x402afe64,
pp_stack=0xbfffedec, n=2, 
    na=2, nk=0) at Python/ceval.c:3518
#13 0x080a7036 in call_function (pp_stack=0xbfffedec,
oparg=1)
    at Python/ceval.c:3458
---Type <return> to continue, or q <return> to quit---
#14 0x080a5667 in eval_frame (f=0x81bc834) at
Python/ceval.c:2116
#15 0x080a65f3 in PyEval_EvalCodeEx (co=0x402641a0,
globals=0x4027335c, 
    locals=0x0, args=0x40345b00, argcount=3, kws=0x0,
kwcount=0, 
    defs=0x402b2db8, defcount=2, closure=0x0) at
Python/ceval.c:2663
#16 0x080e3def in function_call (func=0x402afe2c,
arg=0x40345af4, kw=0x0)
    at Objects/funcobject.c:504
#17 0x0805a004 in PyObject_Call (func=0x402afe2c,
arg=0x40345af4, kw=0x0)
    at Objects/abstract.c:1755
#18 0x08060cc3 in instancemethod_call (func=0x402afe2c,
arg=0x4020d2ec, kw=0x0)
    at Objects/classobject.c:2433
#19 0x0805a004 in PyObject_Call (func=0x403c6c84,
arg=0x4020d2ec, kw=0x0)
    at Objects/abstract.c:1755
#20 0x080a82ab in PyEval_CallObjectWithKeywords
(func=0x403c6c84, 
    arg=0x4020d2ec, kw=0x0) at Python/ceval.c:3346
#21 0x0805cd5f in PyInstance_New (klass=0x402c2b6c,
arg=0x4020d2ec, kw=0x0)
    at Objects/classobject.c:575
#22 0x0805a004 in PyObject_Call (func=0x402c2b6c,
arg=0x4020d2ec, kw=0x0)
    at Objects/abstract.c:1755
#23 0x080a8b66 in do_call (func=0x402c2b6c,
pp_stack=0xbffff2cc, na=2, nk=0)
    at Python/ceval.c:3644
#24 0x080a704d in call_function (pp_stack=0xbffff2cc,
oparg=2)
    at Python/ceval.c:3460
#25 0x080a5667 in eval_frame (f=0x814867c) at
Python/ceval.c:2116
---Type <return> to continue, or q <return> to quit---
#26 0x080a65f3 in PyEval_EvalCodeEx (co=0x40206520,
globals=0x401feb54, 
    locals=0x0, args=0x8159db0, argcount=12,
kws=0x8159de0, kwcount=0, 
    defs=0x40277620, defcount=11, closure=0x0) at
Python/ceval.c:2663
#27 0x080a8adb in fast_function (func=0x40347144,
pp_stack=0xbffff46c, n=12, 
    na=12, nk=0) at Python/ceval.c:3532
#28 0x080a7036 in call_function (pp_stack=0xbffff46c,
oparg=12)
    at Python/ceval.c:3458
#29 0x080a5667 in eval_frame (f=0x8159c04) at
Python/ceval.c:2116
#30 0x080a65f3 in PyEval_EvalCodeEx (co=0x402062e0,
globals=0x401feb54, 
    locals=0x0, args=0x819303c, argcount=15,
kws=0x8193078, kwcount=0, 
    defs=0x4026c628, defcount=14, closure=0x0) at
Python/ceval.c:2663
#31 0x080a8adb in fast_function (func=0x4034709c,
pp_stack=0xbffff60c, n=15, 
    na=15, nk=0) at Python/ceval.c:3532
#32 0x080a7036 in call_function (pp_stack=0xbffff60c,
oparg=15)
    at Python/ceval.c:3458
#33 0x080a5667 in eval_frame (f=0x8192ea4) at
Python/ceval.c:2116
#34 0x080a8a77 in fast_function (func=0x40202c34,
pp_stack=0xbffff71c, n=1, 
    na=1, nk=0) at Python/ceval.c:3518
#35 0x080a7036 in call_function (pp_stack=0xbffff71c,
oparg=1)
    at Python/ceval.c:3458
#36 0x080a5667 in eval_frame (f=0x812444c) at
Python/ceval.c:2116
#37 0x080a65f3 in PyEval_EvalCodeEx (co=0x401ff2e0,
globals=0x401b879c, 
    locals=0x401b879c, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, closure=0x0) at Python/ceval.c:2663
#38 0x080a8976 in PyEval_EvalCode (co=0x401ff2e0,
globals=0x401b879c, 
    locals=0x401b879c) at Python/ceval.c:542
#39 0x080c4db1 in run_node (n=0x4019f488, 
    filename=0xbffffa73 "commandLine.py",
globals=0x401b879c, locals=0x401b879c, 
    flags=0xbffff89c) at Python/pythonrun.c:1265
#40 0x080c3781 in PyRun_SimpleFileExFlags (fp=0x8122288, 
    filename=0xbffffa73 "commandLine.py", closeit=1,
flags=0xbffff89c)
    at Python/pythonrun.c:862
#41 0x0805506a in Py_Main (argc=2, argv=0xbffff934) at
Modules/main.c:415
#42 0x4007e507 in __libc_start_main (main=0x8054980
<main>, argc=2, 
    ubp_av=0xbffff934, init=0x8053cb0 <_init>,
fini=0x80e6ae0 <_fini>, 
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff92c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) 


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

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

From noreply at sourceforge.net  Tue Feb 10 14:17:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 10 15:26:13 2004
Subject: [ python-Bugs-894599 ] Win32 installer should add python's
	directory to system path
Message-ID: <E1AqdNc-00064s-00@sc8-sf-web3.sourceforge.net>

Bugs item #894599, was opened at 2004-02-10 20:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=894599&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Viktor Ferenczi (complex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win32 installer should add python's directory to system path

Initial Comment:
Win32 installer should add python's base directory to 
the system path to allow executing Python.exe 
anywhere. If you use an editor like SciTE a hotkey (F5) 
will start your script with a command line like:

pythonw.exe your_script.py

The system path must be set correctly to allow this 
command. This setting must be done on each machine 
with python installed. In a while classroom with 30 
machines it can be very cumbersome. An installation 
option would be useful in most cases, especially 
with "yes" default.

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

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

From noreply at sourceforge.net  Tue Feb 10 10:54:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 10 15:27:20 2004
Subject: [ python-Bugs-893610 ] Segmentation fault running XSV
Message-ID: <E1AqaDS-0003Sf-00@sc8-sf-web4.sourceforge.net>

Bugs item #893610, was opened at 2004-02-09 19:46
Message generated for change (Comment added) made by jbcombes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893610&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean-Baptiste Combes (jbcombes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault running XSV

Initial Comment:
Python 2.3.* segfaults while running XSV. Python 2.2 is OK
I have no clue about what may be the problem.
Here is a backtrace by GDB :

(gdb) run commandLine.py

[New Thread 1024 (LWP 29583)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 29583)]
__pthread_mutex_lock (mutex=0x475) at mutex.c:99
99      mutex.c: No such file or directory.
        in mutex.c
(gdb) bt
#0  __pthread_mutex_lock (mutex=0x475) at mutex.c:99
#1  0x400e2be8 in __libc_free (mem=0x4029d528) at
malloc.c:3152
#2  0x402f0dcf in Item_Dealloc (self=0x4029d528) at
NSLintermodule.c:2641
#3  0x080a7092 in call_function (pp_stack=0xbfffea2c,
oparg=2)
    at Python/ceval.c:3467
#4  0x080a5667 in eval_frame (f=0x818a42c) at
Python/ceval.c:2116
#5  0x080a65f3 in PyEval_EvalCodeEx (co=0x402b6720,
globals=0x40273714, 
    locals=0x0, args=0x81e69d8, argcount=2,
kws=0x81e69e0, kwcount=0, 
    defs=0x403b5a38, defcount=1, closure=0x0) at
Python/ceval.c:2663
#6  0x080a8adb in fast_function (func=0x4025ef7c,
pp_stack=0xbfffebcc, n=2, 
    na=2, nk=0) at Python/ceval.c:3532
#7  0x080a7036 in call_function (pp_stack=0xbfffebcc,
oparg=2)
    at Python/ceval.c:3458
#8  0x080a5667 in eval_frame (f=0x81e6874) at
Python/ceval.c:2116
#9  0x080a8a77 in fast_function (func=0x4025ef0c,
pp_stack=0xbfffecdc, n=2, 
    na=2, nk=0) at Python/ceval.c:3518
#10 0x080a7036 in call_function (pp_stack=0xbfffecdc,
oparg=2)
    at Python/ceval.c:3458
#11 0x080a5667 in eval_frame (f=0x816c6d4) at
Python/ceval.c:2116
#12 0x080a8a77 in fast_function (func=0x402afe64,
pp_stack=0xbfffedec, n=2, 
    na=2, nk=0) at Python/ceval.c:3518
#13 0x080a7036 in call_function (pp_stack=0xbfffedec,
oparg=1)
    at Python/ceval.c:3458
---Type <return> to continue, or q <return> to quit---
#14 0x080a5667 in eval_frame (f=0x81bc834) at
Python/ceval.c:2116
#15 0x080a65f3 in PyEval_EvalCodeEx (co=0x402641a0,
globals=0x4027335c, 
    locals=0x0, args=0x40345b00, argcount=3, kws=0x0,
kwcount=0, 
    defs=0x402b2db8, defcount=2, closure=0x0) at
Python/ceval.c:2663
#16 0x080e3def in function_call (func=0x402afe2c,
arg=0x40345af4, kw=0x0)
    at Objects/funcobject.c:504
#17 0x0805a004 in PyObject_Call (func=0x402afe2c,
arg=0x40345af4, kw=0x0)
    at Objects/abstract.c:1755
#18 0x08060cc3 in instancemethod_call (func=0x402afe2c,
arg=0x4020d2ec, kw=0x0)
    at Objects/classobject.c:2433
#19 0x0805a004 in PyObject_Call (func=0x403c6c84,
arg=0x4020d2ec, kw=0x0)
    at Objects/abstract.c:1755
#20 0x080a82ab in PyEval_CallObjectWithKeywords
(func=0x403c6c84, 
    arg=0x4020d2ec, kw=0x0) at Python/ceval.c:3346
#21 0x0805cd5f in PyInstance_New (klass=0x402c2b6c,
arg=0x4020d2ec, kw=0x0)
    at Objects/classobject.c:575
#22 0x0805a004 in PyObject_Call (func=0x402c2b6c,
arg=0x4020d2ec, kw=0x0)
    at Objects/abstract.c:1755
#23 0x080a8b66 in do_call (func=0x402c2b6c,
pp_stack=0xbffff2cc, na=2, nk=0)
    at Python/ceval.c:3644
#24 0x080a704d in call_function (pp_stack=0xbffff2cc,
oparg=2)
    at Python/ceval.c:3460
#25 0x080a5667 in eval_frame (f=0x814867c) at
Python/ceval.c:2116
---Type <return> to continue, or q <return> to quit---
#26 0x080a65f3 in PyEval_EvalCodeEx (co=0x40206520,
globals=0x401feb54, 
    locals=0x0, args=0x8159db0, argcount=12,
kws=0x8159de0, kwcount=0, 
    defs=0x40277620, defcount=11, closure=0x0) at
Python/ceval.c:2663
#27 0x080a8adb in fast_function (func=0x40347144,
pp_stack=0xbffff46c, n=12, 
    na=12, nk=0) at Python/ceval.c:3532
#28 0x080a7036 in call_function (pp_stack=0xbffff46c,
oparg=12)
    at Python/ceval.c:3458
#29 0x080a5667 in eval_frame (f=0x8159c04) at
Python/ceval.c:2116
#30 0x080a65f3 in PyEval_EvalCodeEx (co=0x402062e0,
globals=0x401feb54, 
    locals=0x0, args=0x819303c, argcount=15,
kws=0x8193078, kwcount=0, 
    defs=0x4026c628, defcount=14, closure=0x0) at
Python/ceval.c:2663
#31 0x080a8adb in fast_function (func=0x4034709c,
pp_stack=0xbffff60c, n=15, 
    na=15, nk=0) at Python/ceval.c:3532
#32 0x080a7036 in call_function (pp_stack=0xbffff60c,
oparg=15)
    at Python/ceval.c:3458
#33 0x080a5667 in eval_frame (f=0x8192ea4) at
Python/ceval.c:2116
#34 0x080a8a77 in fast_function (func=0x40202c34,
pp_stack=0xbffff71c, n=1, 
    na=1, nk=0) at Python/ceval.c:3518
#35 0x080a7036 in call_function (pp_stack=0xbffff71c,
oparg=1)
    at Python/ceval.c:3458
#36 0x080a5667 in eval_frame (f=0x812444c) at
Python/ceval.c:2116
#37 0x080a65f3 in PyEval_EvalCodeEx (co=0x401ff2e0,
globals=0x401b879c, 
    locals=0x401b879c, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, closure=0x0) at Python/ceval.c:2663
#38 0x080a8976 in PyEval_EvalCode (co=0x401ff2e0,
globals=0x401b879c, 
    locals=0x401b879c) at Python/ceval.c:542
#39 0x080c4db1 in run_node (n=0x4019f488, 
    filename=0xbffffa73 "commandLine.py",
globals=0x401b879c, locals=0x401b879c, 
    flags=0xbffff89c) at Python/pythonrun.c:1265
#40 0x080c3781 in PyRun_SimpleFileExFlags (fp=0x8122288, 
    filename=0xbffffa73 "commandLine.py", closeit=1,
flags=0xbffff89c)
    at Python/pythonrun.c:862
#41 0x0805506a in Py_Main (argc=2, argv=0xbffff934) at
Modules/main.c:415
#42 0x4007e507 in __libc_start_main (main=0x8054980
<main>, argc=2, 
    ubp_av=0xbffff934, init=0x8053cb0 <_init>,
fini=0x80e6ae0 <_fini>, 
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff92c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) 


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

>Comment By: Jean-Baptiste Combes (jbcombes)
Date: 2004-02-10 16:54

Message:
Logged In: YES 
user_id=116408

Quite strange. It works on Linux Mandrake 9.1, and segfaults
on redhat 7.2.

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

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

From noreply at sourceforge.net  Tue Feb 10 17:44:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 10 17:44:46 2004
Subject: [ python-Bugs-894743 ] build_ssl can't find ActiveState Perl from
	unusual locations
Message-ID: <E1Aqgc6-00029p-00@sc8-sf-web3.sourceforge.net>

Bugs item #894743, was opened at 2004-02-10 14:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=894743&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Heikki Toivonen (hjtoi)
Assigned to: Nobody/Anonymous (nobody)
Summary: build_ssl can't find ActiveState Perl from unusual locations

Initial Comment:
Downloaded Python 2.3.3 and tried building it with VC++
7.1 on Windows XP. Got an error message that my cygwin
perl is the only perl installed on my system and I need
ActiveState Perl. Trouble is, I do have that, but it is
installed in a non-standard location. The build_ssl.py
only looks in two directories for versions of perl. I
suggest it should additionally do "which perl" or
something similar to find the first Perl in the users path.

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

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

From noreply at sourceforge.net  Wed Feb 11 11:36:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 11 11:36:58 2004
Subject: [ python-Feature Requests-894936 ] Have a split corresponding with
	os.path.join
Message-ID: <E1AqxLh-00042u-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #894936, was opened at 2004-02-11 11:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=894936&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nicolas Fleury (nidoizo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Have a split corresponding with os.path.join

Initial Comment:
I would be nice to have a function to do the exact
opposite of os.path.join, something like an
os.path.splitall or fullsplit.

Rationale:
Currently, on Windows, using os.path.split produce the
following result:
 os.path.split('Z:/xyz') => ('Z:/', 'xyz')
It exceptionaly keep the \ after the drive.  This
exception makes str.split incompatible with
os.path.join that is expecting the \.

Spliting fully a path is useful when transforming
absolute paths to relative paths.  I could also be nice
to have a function to do that in os.path.


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

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

From noreply at sourceforge.net  Wed Feb 11 18:18:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 11 23:37:28 2004
Subject: [ python-Bugs-832159 ] C++ extensions using SWIG and MinGW
Message-ID: <E1Ar3cK-0000Rs-00@sc8-sf-web2.sourceforge.net>

Bugs item #832159, was opened at 2003-10-28 23:27
Message generated for change (Comment added) made by woodsplitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832159&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Allen Chan (alydar)
Assigned to: Nobody/Anonymous (nobody)
Summary: C++ extensions using SWIG and MinGW

Initial Comment:
Using the following three files:

-- begin files -----
/* hello.cpp */
#include <stdio.h>
void hello()
{
    printf("hello world\n");
}
------------------
/* hello.i */
%module hello
extern void hello();
------------------
# setup.py
import distutils
from distutils.core import setup, Extension

setup(name = "Hello World",
        version = "1.0",
        ext_modules = [Extension("_hello",
            ["hello.i","hello.cpp"])])
-- end files -------


executing the command:
 "python setup.py build_ext -cmingw32 --swig-cpp -f"
creates the following output:

-- begin output --
running build_ext
building '_hello' extension
swigging hello.i to hello_wrap.cpp
...
[ snipped ]
...
cc -mno-cygwin -shared -s build\temp.win32-2.3
\Release\hello_wrap.o build\temp.w
in32-2.3\Release\hello.o build\temp.win32-2.3
\Release\_hello.def -LC:\p\Python23
\libs -LC:\p\Python23\PCBuild -lpython23 -o 
build\lib.win32-2.3\_hello.pyd
error: command 'cc' failed: No such file or directory
-- end output --

It appears that unixccompiler.py defaults compiler_cxx 
to use "cc" and then uses it for the linking, and 
cygwinccompiler.py does not override the compiler_cxx 
entry.  If the self.set_executable() call in the __init__*( 
function of the Mingw32Compiler class also sets 
compiler_cxx to use "g++", then the extension build will 
work.



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

Comment By: David Rushby (woodsplitter)
Date: 2004-02-11 18:18

Message:
Logged In: YES 
user_id=414645

I also encountered this bug while trying to build a C++
extension with no SWIG involved.

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

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

From noreply at sourceforge.net  Thu Feb 12 02:42:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 02:43:04 2004
Subject: [ python-Bugs-895510 ] email library Parser can't parse some
	messages
Message-ID: <E1ArBUU-0005Sr-00@sc8-sf-web1.sourceforge.net>

Bugs item #895510, was opened at 2004-02-12 08:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=895510&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jan Ondrej (ondrejj)
Assigned to: Nobody/Anonymous (nobody)
Summary: email library Parser can't parse some messages

Initial Comment:
The email library can't decode some emails with one bad
part. This part is ignored (not decoded) by other
software. I am developing an antivir software and I
need to decode these messages.

There is the code, which raises an error:
  if line[0] in ' \t':
      if not lastheader:
        print "Errors.HeaderParseError"
            raise Errors.HeaderParseError(
                      'Continuation line seen before
first header')

There is an example attached. It contains a space
before "Content-Type:" in first part. This part is
buggy, but next part can contain important data.

If it is not a bug but an RFC implementation, please
tell me, how I can decode these emails.

I think, this problem is in all versions of this
library (also in CVS), because this code is not changed
in it.


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

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

From noreply at sourceforge.net  Thu Feb 12 02:45:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 02:46:01 2004
Subject: [ python-Bugs-895510 ] email library Parser can't parse some
	messages
Message-ID: <E1ArBXJ-00033S-00@sc8-sf-web2.sourceforge.net>

Bugs item #895510, was opened at 2004-02-12 08:42
Message generated for change (Comment added) made by ondrejj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=895510&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jan Ondrej (ondrejj)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email library Parser can't parse some messages

Initial Comment:
The email library can't decode some emails with one bad
part. This part is ignored (not decoded) by other
software. I am developing an antivir software and I
need to decode these messages.

There is the code, which raises an error:
  if line[0] in ' \t':
      if not lastheader:
        print "Errors.HeaderParseError"
            raise Errors.HeaderParseError(
                      'Continuation line seen before
first header')

There is an example attached. It contains a space
before "Content-Type:" in first part. This part is
buggy, but next part can contain important data.

If it is not a bug but an RFC implementation, please
tell me, how I can decode these emails.

I think, this problem is in all versions of this
library (also in CVS), because this code is not changed
in it.


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

>Comment By: Jan Ondrej (ondrejj)
Date: 2004-02-12 08:45

Message:
Logged In: YES 
user_id=799485

I am sorry, file was not attached.

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

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

From noreply at sourceforge.net  Thu Feb 12 04:01:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 04:02:10 2004
Subject: [ python-Bugs-895560 ] - another minor typo
Message-ID: <E1ArCj0-0008Er-00@sc8-sf-web3.sourceforge.net>

Bugs item #895560, was opened at 2004-02-12 10:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=895560&group_id=5470

Category: Documentation
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Nikolay Diakov (diakov)
Assigned to: Nobody/Anonymous (nobody)
Summary: - another minor typo

Initial Comment:
In the Python online tutorial I read:
"
9.9 Iterators 

By now, you've probably noticed that most container 
objects can looped over using a for statement:
"

while it should probably read:

"...can be looped..."

Keep up the good work,
  Nik

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

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

From noreply at sourceforge.net  Thu Feb 12 04:15:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 04:15:55 2004
Subject: [ python-Bugs-895567 ] os.listdir fails for pathprefix \?\d:...
Message-ID: <E1ArCwC-0001Vi-00@sc8-sf-web4.sourceforge.net>

Bugs item #895567, was opened at 2004-02-12 09:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=895567&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Guenter Kruschina (kruschina)
Assigned to: Thomas Heller (theller)
Summary: os.listdir fails for pathprefix \?\d:...

Initial Comment:
The  function os.listdir() fails with arguments
beggining with \?\... . This is necessary under
windows to switch off pathchecking  for all
Win32-Widecharacter functions. The problem is located
in the posixmodule.

A diff -u will show the solution for this problem:

--- posixmodule.c       2004-01-30 16:51:18.768574400 +0100
+++ posixmodule.c.org   2003-12-03 02:21:01.000000000 +0100
@@ -1386,7 +1386,7 @@
                        len = wcslen(wnamebuf);
                        wch = (len > 0) ?
wnamebuf[len-1] : L'\0';
                        if (wch != L'/' && wch != L'\'
&& wch != L':')
-                               wnamebuf[len++] = L'\';
+                               wnamebuf[len++] = L'/';
                        wcscpy(wnamebuf + len, L"*.*");
                        if ((d = PyList_New(0)) == NULL)
                                return NULL;


By the way: The functions isdir..isfile...etc also does
not work with the pathprefix \?
----------------------------------------------------------------------

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

From noreply at sourceforge.net  Thu Feb 12 04:57:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 04:58:13 2004
Subject: [ python-Bugs-895560 ] - another minor typo
Message-ID: <E1ArDbD-0002Sk-00@sc8-sf-web3.sourceforge.net>

Bugs item #895560, was opened at 2004-02-12 04:01
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=895560&group_id=5470

Category: Documentation
Group: Not a Bug
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nikolay Diakov (diakov)
Assigned to: Nobody/Anonymous (nobody)
Summary: - another minor typo

Initial Comment:
In the Python online tutorial I read:
"
9.9 Iterators 

By now, you've probably noticed that most container 
objects can looped over using a for statement:
"

while it should probably read:

"...can be looped..."

Keep up the good work,
  Nik

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-12 04:57

Message:
Logged In: YES 
user_id=80475

Fixed.  Thanks.

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

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

From noreply at sourceforge.net  Thu Feb 12 09:05:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 09:18:53 2004
Subject: [ python-Bugs-884064 ] metaclasses and __unicode__
Message-ID: <E1ArHSj-0008Qe-00@sc8-sf-web1.sourceforge.net>

Bugs item #884064, was opened at 2004-01-25 10:24
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=884064&group_id=5470

Category: Type/class unification
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Christoph Simon (arundo)
>Assigned to: Michael Hudson (mwh)
Summary: metaclasses and __unicode__

Initial Comment:
class Metaklasse (type) :
    def __str__ (cls) :
        return 'string'
    def __unicode__ (cls) :
        return u'unicode'
    def __int__ (cls) :
        return 7

class Klasse :
    __metaclass__ = Metaklasse
    def __str__ (cls) :
        return 'text'
    def __unicode__ (cls) :
        return u'unicodetext'
    def __int__ (cls) :
        return 9

print str(Klasse)
#print unicode(Klasse)
print int(Klasse)

print str(Klasse())
print unicode(Klasse())
print int(Klasse())

print unicode(Klasse)

The last print statemant raises an error

Traceback (most recent call last):
  File "Metaklasse.py", line 26, in -toplevel-
    print unicode(Klasse)
TypeError: unbound method __unicode__() must be called 
with Klasse instance as first argument (got nothing 
instead)

unicode() does not use the __unicode__ function of the 
metaclass. But int() and str() do.

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

>Comment By: Michael Hudson (mwh)
Date: 2004-02-12 14:05

Message:
Logged In: YES 
user_id=6656

Agree with etrepum.

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

Comment By: Bob Ippolito (etrepum)
Date: 2004-01-26 08:00

Message:
Logged In: YES 
user_id=139309

This is a bug in your implementation, not in Python.  On your 
metaclass, __unicode__ must be a descriptor that looks 
something like this.

def metamethod(f, doc=None):
....def __get__(ob):
........return f.__get__(ob, ob.__class__)
....return property(__get__, doc=doc)

try it with the metaclass like this:

class Metaclass(type):
....def __unicode__(self):
........return u'metaclass'
....__unicode__ = metamethod(__unicode__)

(btw: to save you the trouble, it works)

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

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

From noreply at sourceforge.net  Thu Feb 12 09:07:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 09:19:02 2004
Subject: [ python-Bugs-860547 ] Core dump problems
Message-ID: <E1ArHVO-0007K8-00@sc8-sf-web4.sourceforge.net>

Bugs item #860547, was opened at 2003-12-15 20:06
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860547&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Draper (crunch)
>Assigned to: Michael Hudson (mwh)
Summary: Core dump problems

Initial Comment:
Tried to install Python 2.3.3c1

 It keeps core dumping (leaving python.core). I'm not doing 
anything strange, just documented stuff from the manuals. 

  I tried 'gdb -c python.core' and then using 'back', but 
there are no labels compiled in (I hate that...); how can I
get the labels to be included? "./configure --debug" doesn't 
work. 

  I assume without the labels the numbers are 
meaningless. Running this under OpenBSD 3.2. Then, 
where should I submit my core dump (if anywhere?)?





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

>Comment By: Michael Hudson (mwh)
Date: 2004-02-12 14:07

Message:
Logged In: YES 
user_id=6656

This bug report will be closed soon if no update is forthcoming.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-09 03:13

Message:
Logged In: YES 
user_id=80475

Do you still have install problems with the latest Python?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-15 23:12

Message:
Logged In: YES 
user_id=33168

try ./configure --with-pydebug
Do all the tests run?  (make test)

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

Comment By: John Draper (crunch)
Date: 2003-12-15 21:08

Message:
Logged In: YES 
user_id=61606

Further details on the Python core dump:

It core dumps (segmentation fault) when I check the database 
for a certain key. The offending statement is: 
x=database.has_key(keystring). database is open and otherwise 
normal.  The database is "gdbm-1.8.3". The offending key is 
"3012a3ec5c796329fee7c242d4df00d6".


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

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

From noreply at sourceforge.net  Thu Feb 12 09:09:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 09:19:06 2004
Subject: [ python-Bugs-890010 ] Odd warning behaviors
Message-ID: <E1ArHWX-0007OQ-00@sc8-sf-web4.sourceforge.net>

Bugs item #890010, was opened at 2004-02-03 22:25
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Odd warning behaviors

Initial Comment:
This is from Evan Simpson, on the zope-dev list.  The 
bulk have to do with what happens if __name__ is set to 
None:


Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 
2.3.3 problem
http://mail.zope.org/mailman/listinfo/zope-dev

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> range(1.0)
__main__:1: DeprecationWarning: integer argument 
expected, got float
[0]
 >>>

So far, so good.  However:

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> __name__=None
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 63, in 
warn_explicit
     if module[-3:].lower() == ".py":
TypeError: unsubscriptable object
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import warnings
 >>> warnings.simplefilter("error", 
category=DeprecationWarning)
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 92, in 
warn_explicit
     raise message
DeprecationWarning: integer argument expected, got 
float
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import pdb
 >>> __name__ = None
 >>> pdb.run('range(1.0)')
 > <string>(1)?()
(Pdb) s
--Call--
 > /usr/lib/python2.3/warnings.py(24)warn()
-> def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning: 
tp_compare didn't return 
-1 or -2 for exception
   i = max(0, len(stack) - 1)
[traceback snipped]

Looks like something isn't properly propagating 
exceptions.

Cheers,

Evan @ 4-am


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

>Comment By: Michael Hudson (mwh)
Date: 2004-02-12 14:09

Message:
Logged In: YES 
user_id=6656

Is anyone listening?

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 15:05

Message:
Logged In: YES 
user_id=6656

Oops, wrong file.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 15:03

Message:
Logged In: YES 
user_id=6656

How's this?  It's horrible, but I'm not sure that can be avoided.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 13:22

Message:
Logged In: YES 
user_id=6656

OK, the problem is that returning NULL from 
getargs.c:convertsimple indicates *success* (argh!).

Fixing that provokes weird errors from handle_range_longs.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 12:10

Message:
Logged In: YES 
user_id=6656

Might this be specific to range()?

[mwh@pc150 build]$ ./python.exe -Werror
Python 2.4a0 (#3, Feb  3 2004, 19:23:25) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> range(5.0)
[]

range()'s argument handling is somewhat odd

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

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

From noreply at sourceforge.net  Thu Feb 12 16:03:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 16:03:56 2004
Subject: [ python-Bugs-896052 ] symtable module not documented
Message-ID: <E1ArNzP-0006EY-00@sc8-sf-web2.sourceforge.net>

Bugs item #896052, was opened at 2004-02-12 22:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896052&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter ?strand (astrand)
Assigned to: Nobody/Anonymous (nobody)
Summary: symtable module not documented

Initial Comment:
There is no documentation for the symtable module. It's
not listed in the global module index either. 

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

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

From noreply at sourceforge.net  Thu Feb 12 16:04:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 16:05:28 2004
Subject: [ python-Bugs-896052 ] symtable module not documented
Message-ID: <E1ArO0t-0005uX-00@sc8-sf-web1.sourceforge.net>

Bugs item #896052, was opened at 2004-02-12 22:03
Message generated for change (Settings changed) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896052&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter ?strand (astrand)
>Assigned to: Jeremy Hylton (jhylton)
Summary: symtable module not documented

Initial Comment:
There is no documentation for the symtable module. It's
not listed in the global module index either. 

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

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

From noreply at sourceforge.net  Thu Feb 12 16:08:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 16:11:51 2004
Subject: [ python-Bugs-896061 ] symtable.Symbol.is_global() is strange
Message-ID: <E1ArO4P-000695-00@sc8-sf-web1.sourceforge.net>

Bugs item #896061, was opened at 2004-02-12 22:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896061&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter ?strand (astrand)
Assigned to: Nobody/Anonymous (nobody)
Summary: symtable.Symbol.is_global() is strange

Initial Comment:
The symtable.Symbol.is_global() returns false for
symbols in plain functions:

If the source looks like this:

foo = 1

def fie():
    print foo

Calling is_global() for the "foo" name returns False
(using the fie functions SymbolTable).

With a method, however, it works as expected:

foo = 1

class C:
    def fie(self):
        print foo



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

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

From noreply at sourceforge.net  Thu Feb 12 16:08:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 16:12:42 2004
Subject: [ python-Bugs-896061 ] symtable.Symbol.is_global() is strange
Message-ID: <E1ArO4j-0006AR-00@sc8-sf-web1.sourceforge.net>

Bugs item #896061, was opened at 2004-02-12 22:08
Message generated for change (Settings changed) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896061&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter ?strand (astrand)
>Assigned to: Jeremy Hylton (jhylton)
Summary: symtable.Symbol.is_global() is strange

Initial Comment:
The symtable.Symbol.is_global() returns false for
symbols in plain functions:

If the source looks like this:

foo = 1

def fie():
    print foo

Calling is_global() for the "foo" name returns False
(using the fie functions SymbolTable).

With a method, however, it works as expected:

foo = 1

class C:
    def fie(self):
        print foo



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

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

From noreply at sourceforge.net  Thu Feb 12 19:37:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 19:38:03 2004
Subject: [ python-Bugs-896199 ] Some Carbon modules missing
Message-ID: <E1ArRKd-0003aC-00@sc8-sf-web4.sourceforge.net>

Bugs item #896199, was opened at 2004-02-12 16:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896199&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Some Carbon modules missing

Initial Comment:
The following Carbon sub-packages are missing from the manuals (both the global module index and also the MacOS Toolbox Modules document):
Carbon.File
Carbon.Files
Carbon.Folders

I don't know if any others are missing.

Also, I would like to suggest that the global module index only include a single entry Carbon for the entire Carbon package (which points to the MacOS Toolbox Modules page). This would save clutter and that one page has all the documentation.

Thanks,

-- Russell

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

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

From noreply at sourceforge.net  Thu Feb 12 21:49:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 21:50:29 2004
Subject: [ python-Bugs-896236 ] Unicode problem in os.path.getsize ?
Message-ID: <E1ArTOm-0005Bk-00@sc8-sf-web1.sourceforge.net>

Bugs item #896236, was opened at 2004-02-12 21:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896236&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode problem in os.path.getsize ?

Initial Comment:
I am running on Windows XP 5.1 using python version 2.3.
The following simple code fails on my system.

for dirpath,dirnames,filenames in os.walk("C:/"):
    for name in filenames:
	pathname = os.path.join(dirpath,name)
	size = os.path.getsize(pathname)
	print size, pathname

I get an error from getsize that the file given by 
pathname does not exist.  When it breaks, the
variable "name" contains two question marks, which
makes me think that this is a Unicode problem.

In any case, shouldn't names returned by walk be
acceptable in all cases to getsize???




 
            
            


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

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

From noreply at sourceforge.net  Thu Feb 12 23:55:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 12 23:56:06 2004
Subject: [ python-Bugs-889200 ] bundlebuilder standalone app doesn't fully
	quit
Message-ID: <E1ArVMI-0004lh-00@sc8-sf-web4.sourceforge.net>

Bugs item #889200, was opened at 2004-02-02 13:08
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder standalone app doesn't fully quit

Initial Comment:
I used bundlebuilder to create a fully standalone app (well, it fails on Jaguar, alas, but the python framework is inside the app). It works fine, but when I quit the app and try to delete it I get the following message from Finder and the item "python" in the .app is not deleted:

The operation cannot be completed because the item "Python" is in use.

The only way I've found to delete the app is to REBOOT. Simply logging out and in again does not do the job (which I find quite startling).

I worked around the problem by making the app semi_standalone, but would rather have it fully self-contained 

It's a huge app; I've not tried to break it down, but some things to consider:
- it uses networking (though I need not make a connection to cause this problem)
- it uses Tkinter (and yes the Tcl and Tk frameworks were installed in the app along with the Python framework)
- it uses a few threads for networking (again, though, the problem occurs even if no connection is ever made, suggesting that no threads have to be started to cause the problem)


-- Russell

I have attached the two code files I use to build the application (combined in one zip archive).

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

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-12 23:55

Message:
Logged In: YES 
user_id=139309

Was the standalone bundle created on Jaguar or Panther?

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

Comment By: Jack Jansen (jackjansen)
Date: 2004-02-06 18:17

Message:
Logged In: YES 
user_id=45365

Russell,
could you try using "ps" (probably "ps -x", both before running the .app 
and after running it) to check that the application has indeed fully exited? 
The fact that you mention there are multiple threads somehow suggests 
that there is something still using that Python...

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

Comment By: Russell Owen (reowen)
Date: 2004-02-02 13:10

Message:
Logged In: YES 
user_id=431773

Note: the included BuildMacTUI.py uses semi_standalone = True, but the problem only occurs if I use standalone = True instead. Sorry for the potential confusion.

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

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

From noreply at sourceforge.net  Fri Feb 13 03:24:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 13 03:25:42 2004
Subject: [ python-Bugs-896330 ] pyconfig.h is not placed in --includedir
Message-ID: <E1ArYd8-0000hO-00@sc8-sf-web2.sourceforge.net>

Bugs item #896330, was opened at 2004-02-13 09:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896330&group_id=5470

Category: Installation
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: G?ran Uddeborg (goeran)
Assigned to: Nobody/Anonymous (nobody)
Summary: pyconfig.h is not placed in --includedir

Initial Comment:
When configuring Python with an explicit --includedir
most of the header files do turn up in this directory.
 But the pyconfig.h is still placed in $(prefix)/include.

I assume it is a bug, and this file too should be
placed according to --includedir.

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

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

From noreply at sourceforge.net  Fri Feb 13 07:35:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 13 07:36:24 2004
Subject: [ python-Bugs-891367 ] dict.get() evaluates second parameter even
	if key is present
Message-ID: <E1ArcXl-0006vh-00@sc8-sf-web1.sourceforge.net>

Bugs item #891367, was opened at 2004-02-05 17:06
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891367&group_id=5470

Category: Build
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Claude Belisle (claude_belisle)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict.get() evaluates second parameter even if key is present

Initial Comment:
The optional parameter passed to get gets evaluated
even when the key is indeed present in the dictionary.
See attached file for the code I was using when
stumbling across this behaviour.

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

Comment By: Michael Chermside (mcherm)
Date: 2004-02-13 07:35

Message:
Logged In: YES 
user_id=99874

That's the desired behavior. Python is never "lazy" (technical 
term)... it *always* evaluates all arguments to any function. 
In fact, they are evaluated *before* the function itself is 
invoked, so even if the function CAN decide that it doesn't 
need that parameter after all, it has already been evaluated.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-05 18:07

Message:
Logged In: YES 
user_id=80475

Unfortunately, that it is what it is supposed to do.

Workaround:

try:
    v = mydict[k]
except AttributeError:
    v = defaultmaker()



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

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

From noreply at sourceforge.net  Fri Feb 13 14:18:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 13 14:19:11 2004
Subject: [ python-Bugs-853061 ] Inconsistent behavior of compressing the
	BZip2 format
Message-ID: <E1AripL-0000HT-00@sc8-sf-web2.sourceforge.net>

Bugs item #853061, was opened at 2003-12-03 12:43
Message generated for change (Settings changed) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853061&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Gustavo Niemeyer (niemeyer)
>Summary: Inconsistent behavior of compressing the BZip2 format

Initial Comment:
There are three ways to compress data in bz2 but they 
don't handle an empty string same way.
BZ2File and compress can accept an empty string but 
BZ2Compressor raises ValueError.

>>> import bz2
>>> bz2f = bz2.BZ2File('test', 'w')
>>> bz2f.write('')
>>> bz2f.close()
>>> bz2.compress('')
'BZh9\x17rE8P\x90\x00\x00\x00\x00'
>>> bz2c = bz2.BZ2Compressor()
>>> bz2c.compress('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: the bz2 library has received wrong 
parameters



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

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

From noreply at sourceforge.net  Fri Feb 13 15:27:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 13 15:28:40 2004
Subject: [ python-Bugs-853061 ] Inconsistent behavior of compressing the
	BZip2 format
Message-ID: <E1Arjuk-0000Of-00@sc8-sf-web3.sourceforge.net>

Bugs item #853061, was opened at 2003-12-03 03:43
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853061&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Inconsistent behavior of compressing the BZip2 format

Initial Comment:
There are three ways to compress data in bz2 but they 
don't handle an empty string same way.
BZ2File and compress can accept an empty string but 
BZ2Compressor raises ValueError.

>>> import bz2
>>> bz2f = bz2.BZ2File('test', 'w')
>>> bz2f.write('')
>>> bz2f.close()
>>> bz2.compress('')
'BZh9\x17rE8P\x90\x00\x00\x00\x00'
>>> bz2c = bz2.BZ2Compressor()
>>> bz2c.compress('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: the bz2 library has received wrong 
parameters



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

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2004-02-13 20:27

Message:
Logged In: YES 
user_id=7887

Indeed, it should be allowed. I'll fix that.

Thanks for your report!

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

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

From noreply at sourceforge.net  Fri Feb 13 17:47:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 13 17:48:21 2004
Subject: [ python-Bugs-889500 ] Line 0 SyntaxWarning with duplicate global
	declarations
Message-ID: <E1Arm5Y-00084j-00@sc8-sf-web1.sourceforge.net>

Bugs item #889500, was opened at 2004-02-02 23:39
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889500&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Connelly (jeffconnelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line 0 SyntaxWarning with duplicate global declarations

Initial Comment:
global a
a = "b"
global a

a.py:0: SyntaxWarning: name 'a' is assigned to before
global declaration


This is a fairly minor bug, however, the message is
misleading (the variable is in fact assigned to both
before and after the global declaration). At least, the
line number should be fixed to refer to the second
declaration, and if possible the error message should
be changed to "duplicate global declaration of 'a'".

P.S.: If "global a" is repeated multiple times, the
error message will be repeated, with the same line
number, and no indication that the warning refers to a
different line.



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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-13 17:47

Message:
Logged In: YES 
user_id=593130

>if possible the error message should
be changed to "duplicate global declaration of 'a'".

The ref man does not prohibit duplicate declarations, nor is 
duplication essential to get the misleading line number: 

>>> def f():
...   global a
...   b = 0
...   global b
...
<stdin>:1: SyntaxWarning: name 'b' is assigned to before 
global declaration

It appears that compiler treats additional global declarations 
as continuations of first and only stores one line #, the first, 
for the 'combined' declaration.  If code is too difficult to 
change, perhaps ref man could make note of this ;-)


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

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

From noreply at sourceforge.net  Fri Feb 13 18:45:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 13 18:46:44 2004
Subject: [ python-Bugs-893610 ] Segmentation fault running XSV
Message-ID: <E1Arn0O-0002Qw-00@sc8-sf-web1.sourceforge.net>

Bugs item #893610, was opened at 2004-02-09 13:46
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893610&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean-Baptiste Combes (jbcombes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault running XSV

Initial Comment:
Python 2.3.* segfaults while running XSV. Python 2.2 is OK
I have no clue about what may be the problem.
Here is a backtrace by GDB :

(gdb) run commandLine.py

[New Thread 1024 (LWP 29583)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 29583)]
__pthread_mutex_lock (mutex=0x475) at mutex.c:99
99      mutex.c: No such file or directory.
        in mutex.c
(gdb) bt
#0  __pthread_mutex_lock (mutex=0x475) at mutex.c:99
#1  0x400e2be8 in __libc_free (mem=0x4029d528) at
malloc.c:3152
#2  0x402f0dcf in Item_Dealloc (self=0x4029d528) at
NSLintermodule.c:2641
#3  0x080a7092 in call_function (pp_stack=0xbfffea2c,
oparg=2)
    at Python/ceval.c:3467
#4  0x080a5667 in eval_frame (f=0x818a42c) at
Python/ceval.c:2116
#5  0x080a65f3 in PyEval_EvalCodeEx (co=0x402b6720,
globals=0x40273714, 
    locals=0x0, args=0x81e69d8, argcount=2,
kws=0x81e69e0, kwcount=0, 
    defs=0x403b5a38, defcount=1, closure=0x0) at
Python/ceval.c:2663
#6  0x080a8adb in fast_function (func=0x4025ef7c,
pp_stack=0xbfffebcc, n=2, 
    na=2, nk=0) at Python/ceval.c:3532
#7  0x080a7036 in call_function (pp_stack=0xbfffebcc,
oparg=2)
    at Python/ceval.c:3458
#8  0x080a5667 in eval_frame (f=0x81e6874) at
Python/ceval.c:2116
#9  0x080a8a77 in fast_function (func=0x4025ef0c,
pp_stack=0xbfffecdc, n=2, 
    na=2, nk=0) at Python/ceval.c:3518
#10 0x080a7036 in call_function (pp_stack=0xbfffecdc,
oparg=2)
    at Python/ceval.c:3458
#11 0x080a5667 in eval_frame (f=0x816c6d4) at
Python/ceval.c:2116
#12 0x080a8a77 in fast_function (func=0x402afe64,
pp_stack=0xbfffedec, n=2, 
    na=2, nk=0) at Python/ceval.c:3518
#13 0x080a7036 in call_function (pp_stack=0xbfffedec,
oparg=1)
    at Python/ceval.c:3458
---Type <return> to continue, or q <return> to quit---
#14 0x080a5667 in eval_frame (f=0x81bc834) at
Python/ceval.c:2116
#15 0x080a65f3 in PyEval_EvalCodeEx (co=0x402641a0,
globals=0x4027335c, 
    locals=0x0, args=0x40345b00, argcount=3, kws=0x0,
kwcount=0, 
    defs=0x402b2db8, defcount=2, closure=0x0) at
Python/ceval.c:2663
#16 0x080e3def in function_call (func=0x402afe2c,
arg=0x40345af4, kw=0x0)
    at Objects/funcobject.c:504
#17 0x0805a004 in PyObject_Call (func=0x402afe2c,
arg=0x40345af4, kw=0x0)
    at Objects/abstract.c:1755
#18 0x08060cc3 in instancemethod_call (func=0x402afe2c,
arg=0x4020d2ec, kw=0x0)
    at Objects/classobject.c:2433
#19 0x0805a004 in PyObject_Call (func=0x403c6c84,
arg=0x4020d2ec, kw=0x0)
    at Objects/abstract.c:1755
#20 0x080a82ab in PyEval_CallObjectWithKeywords
(func=0x403c6c84, 
    arg=0x4020d2ec, kw=0x0) at Python/ceval.c:3346
#21 0x0805cd5f in PyInstance_New (klass=0x402c2b6c,
arg=0x4020d2ec, kw=0x0)
    at Objects/classobject.c:575
#22 0x0805a004 in PyObject_Call (func=0x402c2b6c,
arg=0x4020d2ec, kw=0x0)
    at Objects/abstract.c:1755
#23 0x080a8b66 in do_call (func=0x402c2b6c,
pp_stack=0xbffff2cc, na=2, nk=0)
    at Python/ceval.c:3644
#24 0x080a704d in call_function (pp_stack=0xbffff2cc,
oparg=2)
    at Python/ceval.c:3460
#25 0x080a5667 in eval_frame (f=0x814867c) at
Python/ceval.c:2116
---Type <return> to continue, or q <return> to quit---
#26 0x080a65f3 in PyEval_EvalCodeEx (co=0x40206520,
globals=0x401feb54, 
    locals=0x0, args=0x8159db0, argcount=12,
kws=0x8159de0, kwcount=0, 
    defs=0x40277620, defcount=11, closure=0x0) at
Python/ceval.c:2663
#27 0x080a8adb in fast_function (func=0x40347144,
pp_stack=0xbffff46c, n=12, 
    na=12, nk=0) at Python/ceval.c:3532
#28 0x080a7036 in call_function (pp_stack=0xbffff46c,
oparg=12)
    at Python/ceval.c:3458
#29 0x080a5667 in eval_frame (f=0x8159c04) at
Python/ceval.c:2116
#30 0x080a65f3 in PyEval_EvalCodeEx (co=0x402062e0,
globals=0x401feb54, 
    locals=0x0, args=0x819303c, argcount=15,
kws=0x8193078, kwcount=0, 
    defs=0x4026c628, defcount=14, closure=0x0) at
Python/ceval.c:2663
#31 0x080a8adb in fast_function (func=0x4034709c,
pp_stack=0xbffff60c, n=15, 
    na=15, nk=0) at Python/ceval.c:3532
#32 0x080a7036 in call_function (pp_stack=0xbffff60c,
oparg=15)
    at Python/ceval.c:3458
#33 0x080a5667 in eval_frame (f=0x8192ea4) at
Python/ceval.c:2116
#34 0x080a8a77 in fast_function (func=0x40202c34,
pp_stack=0xbffff71c, n=1, 
    na=1, nk=0) at Python/ceval.c:3518
#35 0x080a7036 in call_function (pp_stack=0xbffff71c,
oparg=1)
    at Python/ceval.c:3458
#36 0x080a5667 in eval_frame (f=0x812444c) at
Python/ceval.c:2116
#37 0x080a65f3 in PyEval_EvalCodeEx (co=0x401ff2e0,
globals=0x401b879c, 
    locals=0x401b879c, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, closure=0x0) at Python/ceval.c:2663
#38 0x080a8976 in PyEval_EvalCode (co=0x401ff2e0,
globals=0x401b879c, 
    locals=0x401b879c) at Python/ceval.c:542
#39 0x080c4db1 in run_node (n=0x4019f488, 
    filename=0xbffffa73 "commandLine.py",
globals=0x401b879c, locals=0x401b879c, 
    flags=0xbffff89c) at Python/pythonrun.c:1265
#40 0x080c3781 in PyRun_SimpleFileExFlags (fp=0x8122288, 
    filename=0xbffffa73 "commandLine.py", closeit=1,
flags=0xbffff89c)
    at Python/pythonrun.c:862
#41 0x0805506a in Py_Main (argc=2, argv=0xbffff934) at
Modules/main.c:415
#42 0x4007e507 in __libc_start_main (main=0x8054980
<main>, argc=2, 
    ubp_av=0xbffff934, init=0x8053cb0 <_init>,
fini=0x80e6ae0 <_fini>, 
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff92c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) 


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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-13 18:45

Message:
Logged In: YES 
user_id=593130

I know nothing of XSV, even if it is C or Python coded, so 
can only offer generic comment:  You are more likely to get 
attention of voluteer patchers if you can pinpoint the line of 
XSV code inducing the segfault.

>It works on Linux Mandrake 9.1, and segfaults
on redhat 7.2

The header lines displayed in interactive mode describing the 
respective builds might help explain.  A possible reason is a 
bug in the compiler or compilation mode (such as 
optimization) in one and not the other.

Good luck.  This is beyond my competance.

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

Comment By: Jean-Baptiste Combes (jbcombes)
Date: 2004-02-10 10:54

Message:
Logged In: YES 
user_id=116408

Quite strange. It works on Linux Mandrake 9.1, and segfaults
on redhat 7.2.

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

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

From noreply at sourceforge.net  Fri Feb 13 19:10:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 13 19:11:09 2004
Subject: [ python-Bugs-853061 ] Inconsistent behavior of compressing the
	BZip2 format
Message-ID: <E1ArnO2-0006Ab-00@sc8-sf-web2.sourceforge.net>

Bugs item #853061, was opened at 2003-12-03 03:43
Message generated for change (Comment added) made by niemeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853061&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Inconsistent behavior of compressing the BZip2 format

Initial Comment:
There are three ways to compress data in bz2 but they 
don't handle an empty string same way.
BZ2File and compress can accept an empty string but 
BZ2Compressor raises ValueError.

>>> import bz2
>>> bz2f = bz2.BZ2File('test', 'w')
>>> bz2f.write('')
>>> bz2f.close()
>>> bz2.compress('')
'BZh9\x17rE8P\x90\x00\x00\x00\x00'
>>> bz2c = bz2.BZ2Compressor()
>>> bz2c.compress('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: the bz2 library has received wrong 
parameters



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

>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2004-02-14 00:10

Message:
Logged In: YES 
user_id=7887

Committed as:

Modules/bz2module.c: 1.22
Misc/NEWS: 1.933


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

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2004-02-13 20:27

Message:
Logged In: YES 
user_id=7887

Indeed, it should be allowed. I'll fix that.

Thanks for your report!

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

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

From noreply at sourceforge.net  Fri Feb 13 19:47:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 13 19:47:52 2004
Subject: [ python-Bugs-896236 ] Unicode problem in os.path.getsize ?
Message-ID: <E1ArnxY-0007VM-00@sc8-sf-web2.sourceforge.net>

Bugs item #896236, was opened at 2004-02-12 21:49
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896236&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode problem in os.path.getsize ?

Initial Comment:
I am running on Windows XP 5.1 using python version 2.3.
The following simple code fails on my system.

for dirpath,dirnames,filenames in os.walk("C:/"):
    for name in filenames:
	pathname = os.path.join(dirpath,name)
	size = os.path.getsize(pathname)
	print size, pathname

I get an error from getsize that the file given by 
pathname does not exist.  When it breaks, the
variable "name" contains two question marks, which
makes me think that this is a Unicode problem.

In any case, shouldn't names returned by walk be
acceptable in all cases to getsize???




 
            
            


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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-13 19:47

Message:
Logged In: YES 
user_id=593130

Though it might be, I suspect that this is not a Python bug.  
Whether is it a Windows design or coding bug in is another 
matter.

>variable "name" contains two question marks, which
>makes me think that this is a Unicode problem.

Since '?' is not legal in filenames, as you seem to know, I 
more believe this is the Windows substitute, in the Win 
function called by os.listdir and os.walk, for illegal characters 
in the filename.  So of course getsize, which wraps os.stat(), 
which calls a system function, chokes on it.

Could be disk bit glitch, or bad program writing directly to 
directory block.  Happened to me once - difficult to get rid of.

What does Windows Explorer show when you visit that 
directory?  Ditto for 'dir' in a CommandPrompt window
(Start/Accessories)? 


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

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

From noreply at sourceforge.net  Fri Feb 13 20:46:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 13 20:47:25 2004
Subject: [ python-Bugs-896236 ] Unicode problem in os.path.getsize ?
Message-ID: <E1Arot7-0001Wz-00@sc8-sf-web2.sourceforge.net>

Bugs item #896236, was opened at 2004-02-12 21:49
Message generated for change (Comment added) made by ronrivest
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896236&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode problem in os.path.getsize ?

Initial Comment:
I am running on Windows XP 5.1 using python version 2.3.
The following simple code fails on my system.

for dirpath,dirnames,filenames in os.walk("C:/"):
    for name in filenames:
	pathname = os.path.join(dirpath,name)
	size = os.path.getsize(pathname)
	print size, pathname

I get an error from getsize that the file given by 
pathname does not exist.  When it breaks, the
variable "name" contains two question marks, which
makes me think that this is a Unicode problem.

In any case, shouldn't names returned by walk be
acceptable in all cases to getsize???




 
            
            


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

>Comment By: Ronald L. Rivest (ronrivest)
Date: 2004-02-13 20:46

Message:
Logged In: YES 
user_id=863876

TJREEDY -- Thanks for the reply...

To answer your questions:
   (1) What does Windows show when I visit the directory?
        -- I have several files in this directory that have
the same
            problem.  It is a hard, reproducible problem, not a
            transient glitch.   The files are mp3 files that
have 
            the name "prelude.mp3", except that the first "e" is
            replaced by two question marks (for Python) or by 
            two "boxes" in Windows Explorer.  I would guess that
            this is some funky representation of the french "e"
            with an "accent aigu".  
    (2) What does "dir" do in a Command Prompt?
        -- From a command prompt, I see two question marks
            at the problematic position.

Does Windows allow one to create filenames with characters
in the filename that are illegal for Windows?  

As I said in the original post, I find it very disturbing that
os.walk should return a filename that os.path.exists says
doesn't exist!  If you can walk the directory and find the
file, then os.path.exists (or, equivalently, os.path.getsize),
should find it!  This looks like a Python bug to me... no?

    Cheers,
    Ron Rivest



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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-13 19:47

Message:
Logged In: YES 
user_id=593130

Though it might be, I suspect that this is not a Python bug.  
Whether is it a Windows design or coding bug in is another 
matter.

>variable "name" contains two question marks, which
>makes me think that this is a Unicode problem.

Since '?' is not legal in filenames, as you seem to know, I 
more believe this is the Windows substitute, in the Win 
function called by os.listdir and os.walk, for illegal characters 
in the filename.  So of course getsize, which wraps os.stat(), 
which calls a system function, chokes on it.

Could be disk bit glitch, or bad program writing directly to 
directory block.  Happened to me once - difficult to get rid of.

What does Windows Explorer show when you visit that 
directory?  Ditto for 'dir' in a CommandPrompt window
(Start/Accessories)? 


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

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

From noreply at sourceforge.net  Sat Feb 14 13:03:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 14 13:04:07 2004
Subject: [ python-Bugs-860547 ] Core dump problems
Message-ID: <E1As48E-0004Sk-00@sc8-sf-web2.sourceforge.net>

Bugs item #860547, was opened at 2003-12-15 15:06
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860547&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: John Draper (crunch)
Assigned to: Michael Hudson (mwh)
Summary: Core dump problems

Initial Comment:
Tried to install Python 2.3.3c1

 It keeps core dumping (leaving python.core). I'm not doing 
anything strange, just documented stuff from the manuals. 

  I tried 'gdb -c python.core' and then using 'back', but 
there are no labels compiled in (I hate that...); how can I
get the labels to be included? "./configure --debug" doesn't 
work. 

  I assume without the labels the numbers are 
meaningless. Running this under OpenBSD 3.2. Then, 
where should I submit my core dump (if anywhere?)?





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

Comment By: Michael Hudson (mwh)
Date: 2004-02-12 09:07

Message:
Logged In: YES 
user_id=6656

This bug report will be closed soon if no update is forthcoming.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-08 22:13

Message:
Logged In: YES 
user_id=80475

Do you still have install problems with the latest Python?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-15 18:12

Message:
Logged In: YES 
user_id=33168

try ./configure --with-pydebug
Do all the tests run?  (make test)

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

Comment By: John Draper (crunch)
Date: 2003-12-15 16:08

Message:
Logged In: YES 
user_id=61606

Further details on the Python core dump:

It core dumps (segmentation fault) when I check the database 
for a certain key. The offending statement is: 
x=database.has_key(keystring). database is open and otherwise 
normal.  The database is "gdbm-1.8.3". The offending key is 
"3012a3ec5c796329fee7c242d4df00d6".


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

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

From noreply at sourceforge.net  Sun Feb 15 16:33:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb 15 16:44:22 2004
Subject: [ python-Bugs-897625 ] time.strftime crashes python
Message-ID: <E1AsTt3-0000Rl-00@sc8-sf-web3.sourceforge.net>

Bugs item #897625, was opened at 2004-02-15 21:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897625&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Lynn (tlynn)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.strftime crashes python

Initial Comment:
On Win2k:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Python dumps core.  Is that (ever) expected behaviour?

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

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

From noreply at sourceforge.net  Sun Feb 15 18:41:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb 15 18:42:46 2004
Subject: [ python-Bugs-897625 ] time.strftime crashes python
Message-ID: <E1AsVtJ-0004D8-00@sc8-sf-web1.sourceforge.net>

Bugs item #897625, was opened at 2004-02-15 16:33
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897625&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 7
Submitted By: Tom Lynn (tlynn)
>Assigned to: Brett Cannon (bcannon)
Summary: time.strftime crashes python

Initial Comment:
On Win2k:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Python dumps core.  Is that (ever) expected behaviour?

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-15 18:41

Message:
Logged In: YES 
user_id=80475

It is expected.  Well, now that I've confirmed it on Py2.3.3
and Py2.4, yes ;-) 

Is it desirable?  Heck no.

Brett, can you take a look at this?

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

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

From noreply at sourceforge.net  Sun Feb 15 20:23:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb 15 20:24:57 2004
Subject: [ python-Bugs-897625 ] time.strftime crashes python
Message-ID: <E1AsXUE-00086B-00@sc8-sf-web1.sourceforge.net>

Bugs item #897625, was opened at 2004-02-15 16:33
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897625&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Tom Lynn (tlynn)
Assigned to: Brett Cannon (bcannon)
Summary: time.strftime crashes python

Initial Comment:
On Win2k:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Python dumps core.  Is that (ever) expected behaviour?

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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-15 20:23

Message:
Logged In: YES 
user_id=31435

I assume this is specific to Python on Windows using 
Microsoft's C, since this workalike plain C program also dies 
with a memory error while in the bowels of MS's strftime():

#include <stdio.h>
#include <time.h>

void main() {
    struct tm t;
    char buf[256];
    size_t i;

    t.tm_year = 1900 - 1900;
    t.tm_mon = 1 - 1;
    t.tm_mday = 1;
    t.tm_hour = 13;
    t.tm_min = 0;
    t.tm_sec = 0;
    t.tm_wday = -3;
    t.tm_yday = 0;
    t.tm_isdst = -1;

    printf("calling strftime\n");
    i = strftime(buf, sizeof(buf), "%a", &t);
    printf("i: %d\n", i);
}

The problem is the negative value for tm_wday.  MS strftime 
isn't defensive, and uses the negative tm_wday to index into 
nonsense memory.  Ironically, if C had defined the % operator 
in the sane way (meaning Python's way <wink>), a negative 
tm_wday wouldn't have survived for the C library function to 
see.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-15 18:41

Message:
Logged In: YES 
user_id=80475

It is expected.  Well, now that I've confirmed it on Py2.3.3
and Py2.4, yes ;-) 

Is it desirable?  Heck no.

Brett, can you take a look at this?

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

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

From noreply at sourceforge.net  Sun Feb 15 20:36:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb 15 20:42:52 2004
Subject: [ python-Bugs-798058 ] IDLE / PyOS_InputHook
Message-ID: <E1AsXgN-0002D3-00@sc8-sf-web2.sourceforge.net>

Bugs item #798058, was opened at 2003-08-31 17:45
Message generated for change (Comment added) made by mdehoon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798058&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michiel de Hoon (mdehoon)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE / PyOS_InputHook

Initial Comment:
[This bug report is a follow-up of a discussion with
Matthew Cowler of help@python]

I noticed an inconsistency with the usage of the
PyOS_InputHook variable between Python 2.3's IDLE and
Python run from the (DOS or linux) command prompt. This
problem does not occur with earlier versions of Python.
First I will describe the problem, then why it is
important to me.

The PyOS_InputHook variable can be used to install a
callback function that gets called periodically (via
readline's rl_event_hook) when Python is waiting for
terminal input. When Python is run as a terminal
application (from the DOS or linux command prompt),
PyOS_InputHook is NULL initially. Python C extension
modules can set PyOS_InputHook to a function which is
to be called periodically. This works with Python 2.3
and older versions.

In Python 2.2, IDLE makes use of the PyOS_InputHook
variable, presumably to get messages delivered to the
Tkinter window. Python C extension modules that are
loaded from IDLE find that PyOS_InputHook is not NULL,
and therefore cannot specify a different callback
function via PyOS_InputHook, as that would freeze the
Tkinter window.

Now on Python 2.2, in practice that is not a problem.
IDLE in Python 2.2 runs in a single thread. This thread
contains a message loop (probably hidden in the Tk
library) that takes care of the messages destined for
the Tk window. If we open an additional (non-Tk) window
from our C extension module, then its messages also get
processed by Tk's message loop as it is running in the
same thread. So we don't need an additional message
loop for our non-Tk window, and we don't need to change
PyOS_InputHook.

In Python 2.3, IDLE works differently, as it talks to
its interactive interpreter on the TCP/IP loopback
interface and does not make use of PyOS_InputHook. If I
import my C extension module from IDLE, it shows that
PyOS_InputHook is NULL. In addition, multithreading is
now used, with three threads on Windows and two on
Linux and Mac OS X. (I am not sure where the additional
thread on Windows is coming from). In particular, the C
extension module and Tk's message loop are running in
separate threads. So if I open a non-Tk window from my
C extension module, its messages are not handled by
Tk's message loop.

The solution would be to have a message loop in my C
extension module also, which is how the C extension
module works when Python is run as a terminal
application. As PyOS_InputHook is NULL (both with and
without IDLE) when I import my extension module, I can
point it to a message loop in the extension module
without causing havoc. However, whereas Python without
IDLE calls the function specified by PyOS_InputHook
correctly, Python with IDLE fails to call
PyOS_InputHook. Hence, with IDLE I am stuck in a thread
without a message loop, and no way to provide a message
loop of my own.

If I run IDLE with the "-n" command-line argument to
disable running Python code in a sub-process, there is
only one thread, and I can use that thread's message
loop without problems.

Would it be possible in Python 2.3 to have
PyOS_InputHook called also if IDLE / Tkinter is
running? I would think that that no longer interferes
with the correct operation of Tkinter / IDLE, as after
importing IDLE, PyOS_InputHook is NULL anyway.


This problem is important to me because of the
Windows-port of Pygist (gist scientific plotting
package for Python), which I codeveloped several months
ago. The core graphics routines of Pygist are written
in C for performance reasons. Pygist does not work with
Python 2.3 with IDLE, while it does work with Python
2.2 with IDLE. There are no problems with Python 2.3
run from the DOS command prompt, nor with PythonWin or
PyShell.

The problem with Python 2.3 with IDLE is that the
graphics window no longer receives its messages. In
usual Windows programs, there is one message loop,
which looks like

while (GetMessage(&msg, NULL, 0, 0))
{ TranslateMessage(&msg);
  DispatchMessage(&msg);
}

In Python 2.2 with IDLE, we use Tk's message loop to
get messages delivered to the Pygist graphics window.
When running Python 2.2 and Python 2.3 as a terminal
application, we start our own message loop in the C
extension module and point to it using PyOS_InputHook.
With Python 2.3 with IDLE, Tk's message loop is in a
separate thread, so we can't use it, while at the same
time PyOS_InputHook is being ignored. Hence Pygist's
graphics window freezes.

Note that Pygist is different from many other plotting
packages for Python, as it returns to the Python prompt
after opening a graphics Window (allowing you to modify
the window interactively). So the trick is to let both
the Python interpreter and the graphics window receive
their messages.


With regards,

Michiel de Hoon, University of Tokyo.

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

>Comment By: Michiel de Hoon (mdehoon)
Date: 2004-02-16 10:36

Message:
Logged In: YES 
user_id=488897

I had another look at this and it seems that the problem is
in the Modules/_tkinter.c. If I understand correctly,
tkinter does not use the code in Modules/readline.c, which
contains the call to PyOS_InputHook, and hence
PyOS_InputHook is not being called. Surprisingly, the
tkinter code does set the PyOS_InputHook variable to the
EventHook routine, but this seems to be in vain as
PyOS_InputHook is not being called anyway. I suggest to
resubmit this bug report to the Tkinter category.

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

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

From noreply at sourceforge.net  Mon Feb 16 00:52:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 00:53:30 2004
Subject: [ python-Bugs-897817 ] test_strptime failures on FC2-test
Message-ID: <E1AsbgC-0003Ts-00@sc8-sf-web3.sourceforge.net>

Bugs item #897817, was opened at 2004-02-16 16:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897817&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_strptime failures on FC2-test

Initial Comment:
I'm seeing test_strptime failures on this box, running
a version of Fedora Core that's between 1 and the new
test release.

test test_strptime failed -- Traceback (most recent
call last): 
File "Lib/test/test_strptime.py", line 258, in
test_timezone
    self.failUnlessEqual(strp_output.tm_isdst, 0)
AssertionError: -1 != 0

Note that the following line (which tests GMT) also
fails with a -1.

The underlying failure:
>>> import _strptime
>>> strp_output = _strptime.strptime("UTC", "%Z")
>>> strp_output.tm_isdst
-1
>>> strp_output = _strptime.strptime("GMT", "%Z")
>>> strp_output.tm_isdst
-1


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

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

From noreply at sourceforge.net  Mon Feb 16 01:03:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 01:04:43 2004
Subject: [ python-Bugs-897820 ] db4 4.2 == :-( (test_anydbm and test_bsddb3)
Message-ID: <E1Asbr0-00065s-00@sc8-sf-web4.sourceforge.net>

Bugs item #897820, was opened at 2004-02-16 17:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897820&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: db4 4.2 == :-(  (test_anydbm and test_bsddb3)

Initial Comment:
This machine, running fedora core 2 (test) has db4
4.2.52 installed. test_anydbm fails utterly with this
combination. 
3 of the 4 tests fail, the failing part is the same in
each case:

  File "Lib/anydbm.py", line 83, in open
    return mod.open(file, flag, mode)
  File "Lib/dbhash.py", line 16, in open
    return bsddb.hashopen(file, flag, mode)
  File "Lib/bsddb/__init__.py", line 293, in hashopen
    d.open(file, db.DB_HASH, flags, mode)
DBInvalidArgError: (22, 'Invalid argument --
DB_TRUNCATE illegal with locking specified')

test_bsddb passes, but test_bsddb3 fails with a similar
error:

test test_bsddb3 failed -- Traceback (most recent call
last):
  File "Lib/bsddb/test/test_compat.py", line 82, in
test04_n_flag
    f = hashopen(self.filename, 'n')
  File "Lib/bsddb/__init__.py", line 293, in hashopen
    d.open(file, db.DB_HASH, flags, mode)
DBInvalidArgError: (22, 'Invalid argument --
DB_TRUNCATE illegal with locking specified')



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

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

From noreply at sourceforge.net  Mon Feb 16 03:37:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 03:38:57 2004
Subject: [ python-Bugs-897872 ] Unknown color name on HP-UX
Message-ID: <E1AseGG-0004tg-00@sc8-sf-web4.sourceforge.net>

Bugs item #897872, was opened at 2004-02-16 08:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897872&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unknown color name on HP-UX

Initial Comment:
When I click on a node in the class browser tree widget, 
I get: 

TclError: unknown color name "darkblue".

This is coming from line 253 in TreeWidget.py where the 
background color is hard-coded as "darkblue".

On HP-UX 11.11 there is no entry for "darkblue" in 
rgb.txt.



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

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

From noreply at sourceforge.net  Mon Feb 16 06:28:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 06:29:52 2004
Subject: [ python-Bugs-897935 ] pty.spawn() leaks file descriptors
Message-ID: <E1Asgvg-0002Rn-00@sc8-sf-web3.sourceforge.net>

Bugs item #897935, was opened at 2004-02-16 19:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897935&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: pty.spawn() leaks file descriptors

Initial Comment:
By running the following short program on Linux, you
can see the number of open file descriptors increase:
    import os, pty
    for i in range(10):
        pty.spawn(['true'])
        print len(os.listdir('/proc/%d/fd' % os.getpid()))

This can be fixed by os.close()'ing master_fd.  This
problem seems to exist in CVS head as well as 2.3.

There are also a few changes that would be nice to see
in pty.spawn:

1) get the exit status of the child.  Could be fixed by
adding the following to the end of the function:
    pid, status = os.waitpid(pid, 0)
    return status

2) set master_fd to non-blocking mode, so that the
output is printed to the screen at the speed it is
produced by the child.

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

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

From noreply at sourceforge.net  Mon Feb 16 09:55:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 09:56:32 2004
Subject: [ python-Bugs-896236 ] Unicode problem in os.path.getsize ?
Message-ID: <E1Ask9e-0006VP-00@sc8-sf-web3.sourceforge.net>

Bugs item #896236, was opened at 2004-02-13 03:49
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896236&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode problem in os.path.getsize ?

Initial Comment:
I am running on Windows XP 5.1 using python version 2.3.
The following simple code fails on my system.

for dirpath,dirnames,filenames in os.walk("C:/"):
    for name in filenames:
	pathname = os.path.join(dirpath,name)
	size = os.path.getsize(pathname)
	print size, pathname

I get an error from getsize that the file given by 
pathname does not exist.  When it breaks, the
variable "name" contains two question marks, which
makes me think that this is a Unicode problem.

In any case, shouldn't names returned by walk be
acceptable in all cases to getsize???




 
            
            


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

>Comment By: Martin v. L?wis (loewis)
Date: 2004-02-16 15:55

Message:
Logged In: YES 
user_id=21627

This behaviour is standard behaviour of Win32, and,
disturbing as it may sound, is somewhat outside Python's
control.

When a file is found whose name cannot be represented in the
system code page (CP_ACP, the "ANSI" code page), then
non-representable characters are converted to question
marks. What's worse: "roughly-representable" characters are
sometimes converted to look-alike characters.

When passing back such a file name to the Win32, it will not
find the file, as it does have question marks in it.

Withe the "ANSI" API, there is really no solution. Instead,
you should use Unicode file names, i.e. write

for dirpath,dirnames,filenames in os.walk(u"C:/"):

Closing as "won't fix".

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

Comment By: Ronald L. Rivest (ronrivest)
Date: 2004-02-14 02:46

Message:
Logged In: YES 
user_id=863876

TJREEDY -- Thanks for the reply...

To answer your questions:
   (1) What does Windows show when I visit the directory?
        -- I have several files in this directory that have
the same
            problem.  It is a hard, reproducible problem, not a
            transient glitch.   The files are mp3 files that
have 
            the name "prelude.mp3", except that the first "e" is
            replaced by two question marks (for Python) or by 
            two "boxes" in Windows Explorer.  I would guess that
            this is some funky representation of the french "e"
            with an "accent aigu".  
    (2) What does "dir" do in a Command Prompt?
        -- From a command prompt, I see two question marks
            at the problematic position.

Does Windows allow one to create filenames with characters
in the filename that are illegal for Windows?  

As I said in the original post, I find it very disturbing that
os.walk should return a filename that os.path.exists says
doesn't exist!  If you can walk the directory and find the
file, then os.path.exists (or, equivalently, os.path.getsize),
should find it!  This looks like a Python bug to me... no?

    Cheers,
    Ron Rivest



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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-14 01:47

Message:
Logged In: YES 
user_id=593130

Though it might be, I suspect that this is not a Python bug.  
Whether is it a Windows design or coding bug in is another 
matter.

>variable "name" contains two question marks, which
>makes me think that this is a Unicode problem.

Since '?' is not legal in filenames, as you seem to know, I 
more believe this is the Windows substitute, in the Win 
function called by os.listdir and os.walk, for illegal characters 
in the filename.  So of course getsize, which wraps os.stat(), 
which calls a system function, chokes on it.

Could be disk bit glitch, or bad program writing directly to 
directory block.  Happened to me once - difficult to get rid of.

What does Windows Explorer show when you visit that 
directory?  Ditto for 'dir' in a CommandPrompt window
(Start/Accessories)? 


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

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

From noreply at sourceforge.net  Mon Feb 16 09:44:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 10:03:17 2004
Subject: [ python-Bugs-868864 ] 8-bit string literal with iso8859 coding =>
	crash
Message-ID: <E1AsjzQ-0006aO-00@sc8-sf-web2.sourceforge.net>

Bugs item #868864, was opened at 2004-01-01 18:30
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=868864&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: L. Peter Deutsch (lpd)
Assigned to: Martin v. L?wis (loewis)
Summary: 8-bit string literal with iso8859 coding => crash

Initial Comment:
Environment:
Python 2.3.3, built from unmodified out-of-the-tarball
sources
(./configure, make, make install)
Red Hat Linux 7.3, SMP build from source (2 Athlon CPUs)

Symptom:
python out.py
Segmentation fault


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

>Comment By: Martin v. L?wis (loewis)
Date: 2004-02-16 15:44

Message:
Logged In: YES 
user_id=21627

It's much worse than off-by-one. fp_readl reads size-1 bytes
from the input stream, reencodes them as UTF-8, and tries to
fit them into size bytes. In the example, it tries to put
8860 bytes into space for 8192 bytes.

I believe fp_readl should extend the buffer, using code
similar to tok_nextc.

Alternatively, fp_readl could, conservatively, request only
size/4 bytes from the underlying input stream, knowing that,
for most encodings, converting to UTF-8 will increase the
size at worst by a factor of 4. The assertion that the
result still fits should then become a FatalError.

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

Comment By: Jarek Zgoda (zgoda)
Date: 2004-01-02 09:58

Message:
Logged In: YES 
user_id=92222

Python 2.3.2 (#49, Oct  2 2003, 20:02:00) [MSC v.1200 32 bit
(Intel)] on win32
Windows 2kSP4
Effect is the same - Python crashes with "memory can not be
written".

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-01-01 20:53

Message:
Logged In: YES 
user_id=33168

Looks like there may be an off-by-1 error in the
implementation of PEP263.  Attached is a valgrind report. 
Martin, do you have any ideas?

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

Comment By: L. Peter Deutsch (lpd)
Date: 2004-01-01 18:32

Message:
Logged In: YES 
user_id=8861

'make test' ran with no problems.


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

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

From noreply at sourceforge.net  Mon Feb 16 10:07:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 10:08:45 2004
Subject: [ python-Bugs-888829 ] FAQ 2.3 slices not used
Message-ID: <E1AskLS-0005pl-00@sc8-sf-web1.sourceforge.net>

Bugs item #888829, was opened at 2004-02-02 03:53
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=888829&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Wayne Folta (wfolta)
Assigned to: Nobody/Anonymous (nobody)
Summary: FAQ 2.3 slices not used

Initial Comment:
Python Programming FAQ 4.3

The "iterate through a list in reverse" answer doesn't add 
the 2.3 slice answer:

for x in list[::-1]
       <do something with x>

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

>Comment By: Martin v. L?wis (loewis)
Date: 2004-02-16 16:07

Message:
Logged In: YES 
user_id=21627

Thanks, fixed in programming.ht 1.16.

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

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

From noreply at sourceforge.net  Mon Feb 16 11:42:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 11:43:32 2004
Subject: [ python-Bugs-896236 ] Unicode problem in os.path.getsize ?
Message-ID: <E1Aslp5-0005rM-00@sc8-sf-web2.sourceforge.net>

Bugs item #896236, was opened at 2004-02-12 21:49
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896236&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode problem in os.path.getsize ?

Initial Comment:
I am running on Windows XP 5.1 using python version 2.3.
The following simple code fails on my system.

for dirpath,dirnames,filenames in os.walk("C:/"):
    for name in filenames:
	pathname = os.path.join(dirpath,name)
	size = os.path.getsize(pathname)
	print size, pathname

I get an error from getsize that the file given by 
pathname does not exist.  When it breaks, the
variable "name" contains two question marks, which
makes me think that this is a Unicode problem.

In any case, shouldn't names returned by walk be
acceptable in all cases to getsize???




 
            
            


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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-16 11:42

Message:
Logged In: YES 
user_id=593130

Final comment:

dir and explorer can display stats of files with bad names 
because they get both simultaneously without trying to use 
the bad names.  CommandPrompt equivalent of listdir (or 
walk) followed by getsize (or stat) is 'dir /w' followed by 'dir 
badname', which should also give "File not found' error 
message.

I believe this 'disturbing' behavior results from having filename 
rules that are not enforced by restricting directory disk block 
writes to os functions that respect the rules.

A roundabout fix: replace 'size = ...' with something like
try: size = ...
except WhateverErrorYouGot:
  file = os.popenx('dir %s' % dirpath).read()
   # x = whichever of 1,2,3,4 works
   <find line with badname>
   <parse out file size>

But prefixing 'u' to the root dir looks a lot easier if it gets you 
what you need.


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

Comment By: Martin v. L?wis (loewis)
Date: 2004-02-16 09:55

Message:
Logged In: YES 
user_id=21627

This behaviour is standard behaviour of Win32, and,
disturbing as it may sound, is somewhat outside Python's
control.

When a file is found whose name cannot be represented in the
system code page (CP_ACP, the "ANSI" code page), then
non-representable characters are converted to question
marks. What's worse: "roughly-representable" characters are
sometimes converted to look-alike characters.

When passing back such a file name to the Win32, it will not
find the file, as it does have question marks in it.

Withe the "ANSI" API, there is really no solution. Instead,
you should use Unicode file names, i.e. write

for dirpath,dirnames,filenames in os.walk(u"C:/"):

Closing as "won't fix".

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

Comment By: Ronald L. Rivest (ronrivest)
Date: 2004-02-13 20:46

Message:
Logged In: YES 
user_id=863876

TJREEDY -- Thanks for the reply...

To answer your questions:
   (1) What does Windows show when I visit the directory?
        -- I have several files in this directory that have
the same
            problem.  It is a hard, reproducible problem, not a
            transient glitch.   The files are mp3 files that
have 
            the name "prelude.mp3", except that the first "e" is
            replaced by two question marks (for Python) or by 
            two "boxes" in Windows Explorer.  I would guess that
            this is some funky representation of the french "e"
            with an "accent aigu".  
    (2) What does "dir" do in a Command Prompt?
        -- From a command prompt, I see two question marks
            at the problematic position.

Does Windows allow one to create filenames with characters
in the filename that are illegal for Windows?  

As I said in the original post, I find it very disturbing that
os.walk should return a filename that os.path.exists says
doesn't exist!  If you can walk the directory and find the
file, then os.path.exists (or, equivalently, os.path.getsize),
should find it!  This looks like a Python bug to me... no?

    Cheers,
    Ron Rivest



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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-13 19:47

Message:
Logged In: YES 
user_id=593130

Though it might be, I suspect that this is not a Python bug.  
Whether is it a Windows design or coding bug in is another 
matter.

>variable "name" contains two question marks, which
>makes me think that this is a Unicode problem.

Since '?' is not legal in filenames, as you seem to know, I 
more believe this is the Windows substitute, in the Win 
function called by os.listdir and os.walk, for illegal characters 
in the filename.  So of course getsize, which wraps os.stat(), 
which calls a system function, chokes on it.

Could be disk bit glitch, or bad program writing directly to 
directory block.  Happened to me once - difficult to get rid of.

What does Windows Explorer show when you visit that 
directory?  Ditto for 'dir' in a CommandPrompt window
(Start/Accessories)? 


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

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

From noreply at sourceforge.net  Mon Feb 16 12:57:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 12:58:45 2004
Subject: [ python-Bugs-896236 ] Unicode problem in os.path.getsize ?
Message-ID: <E1Asmzw-0001kq-00@sc8-sf-web3.sourceforge.net>

Bugs item #896236, was opened at 2004-02-13 03:49
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896236&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Ronald L. Rivest (ronrivest)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unicode problem in os.path.getsize ?

Initial Comment:
I am running on Windows XP 5.1 using python version 2.3.
The following simple code fails on my system.

for dirpath,dirnames,filenames in os.walk("C:/"):
    for name in filenames:
	pathname = os.path.join(dirpath,name)
	size = os.path.getsize(pathname)
	print size, pathname

I get an error from getsize that the file given by 
pathname does not exist.  When it breaks, the
variable "name" contains two question marks, which
makes me think that this is a Unicode problem.

In any case, shouldn't names returned by walk be
acceptable in all cases to getsize???




 
            
            


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

>Comment By: Martin v. L?wis (loewis)
Date: 2004-02-16 18:57

Message:
Logged In: YES 
user_id=21627

This is not true: dir and explorer use both the Unicode
("wide") API (FindFirstFileW). Explorer then tries to render
the file name correctly even if it is outside the code page.
If there is no glyph in the font, a square box is displayed.
dir.exe tries to convert the file name into the encoding of
the terminal (typically CP_OEMCP), and replaces them with
question marks on display.

Also, this behaviour is not caused by applications
performing direct IO to the directory disk block. First, XP
does not allow such IO, and second, very few applications
would know to write NTFS correctly. Instead, the problem is
caused by applications which use the "wide" API for file
names to create files, which is a problem for applications
that use the "narrow" API.

If Ron sees two sqare boxes where a single accented e should
be, the application creating the file most likely has messed
up the file name: Windows should be capable of representing
this letter with a single character, and explorer should be
capable of displaying it properly.

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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-16 17:42

Message:
Logged In: YES 
user_id=593130

Final comment:

dir and explorer can display stats of files with bad names 
because they get both simultaneously without trying to use 
the bad names.  CommandPrompt equivalent of listdir (or 
walk) followed by getsize (or stat) is 'dir /w' followed by 'dir 
badname', which should also give "File not found' error 
message.

I believe this 'disturbing' behavior results from having filename 
rules that are not enforced by restricting directory disk block 
writes to os functions that respect the rules.

A roundabout fix: replace 'size = ...' with something like
try: size = ...
except WhateverErrorYouGot:
  file = os.popenx('dir %s' % dirpath).read()
   # x = whichever of 1,2,3,4 works
   <find line with badname>
   <parse out file size>

But prefixing 'u' to the root dir looks a lot easier if it gets you 
what you need.


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

Comment By: Martin v. L?wis (loewis)
Date: 2004-02-16 15:55

Message:
Logged In: YES 
user_id=21627

This behaviour is standard behaviour of Win32, and,
disturbing as it may sound, is somewhat outside Python's
control.

When a file is found whose name cannot be represented in the
system code page (CP_ACP, the "ANSI" code page), then
non-representable characters are converted to question
marks. What's worse: "roughly-representable" characters are
sometimes converted to look-alike characters.

When passing back such a file name to the Win32, it will not
find the file, as it does have question marks in it.

Withe the "ANSI" API, there is really no solution. Instead,
you should use Unicode file names, i.e. write

for dirpath,dirnames,filenames in os.walk(u"C:/"):

Closing as "won't fix".

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

Comment By: Ronald L. Rivest (ronrivest)
Date: 2004-02-14 02:46

Message:
Logged In: YES 
user_id=863876

TJREEDY -- Thanks for the reply...

To answer your questions:
   (1) What does Windows show when I visit the directory?
        -- I have several files in this directory that have
the same
            problem.  It is a hard, reproducible problem, not a
            transient glitch.   The files are mp3 files that
have 
            the name "prelude.mp3", except that the first "e" is
            replaced by two question marks (for Python) or by 
            two "boxes" in Windows Explorer.  I would guess that
            this is some funky representation of the french "e"
            with an "accent aigu".  
    (2) What does "dir" do in a Command Prompt?
        -- From a command prompt, I see two question marks
            at the problematic position.

Does Windows allow one to create filenames with characters
in the filename that are illegal for Windows?  

As I said in the original post, I find it very disturbing that
os.walk should return a filename that os.path.exists says
doesn't exist!  If you can walk the directory and find the
file, then os.path.exists (or, equivalently, os.path.getsize),
should find it!  This looks like a Python bug to me... no?

    Cheers,
    Ron Rivest



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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-14 01:47

Message:
Logged In: YES 
user_id=593130

Though it might be, I suspect that this is not a Python bug.  
Whether is it a Windows design or coding bug in is another 
matter.

>variable "name" contains two question marks, which
>makes me think that this is a Unicode problem.

Since '?' is not legal in filenames, as you seem to know, I 
more believe this is the Windows substitute, in the Win 
function called by os.listdir and os.walk, for illegal characters 
in the filename.  So of course getsize, which wraps os.stat(), 
which calls a system function, chokes on it.

Could be disk bit glitch, or bad program writing directly to 
directory block.  Happened to me once - difficult to get rid of.

What does Windows Explorer show when you visit that 
directory?  Ditto for 'dir' in a CommandPrompt window
(Start/Accessories)? 


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

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

From noreply at sourceforge.net  Mon Feb 16 15:19:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 15:20:10 2004
Subject: [ python-Bugs-898253 ] strftime ignores date format on winxp
Message-ID: <E1AspCo-0005ts-00@sc8-sf-web1.sourceforge.net>

Bugs item #898253, was opened at 2004-02-17 09:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898253&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Sherborne (matiu)
Assigned to: Nobody/Anonymous (nobody)
Summary: strftime ignores date format on winxp

Initial Comment:
On Windows XP in the control panel set your country to
"New Zealand".

This gives a short date format of 'dd-mm-yy'

Now in python:
>>> from time import *
>>> print strftime('%c', localtime)
02/17/04 09:15:10
>>> print strftime('%x', localtime())
02/17/04

This is giving the date in the format 'mm-dd-yy'
(American).

Could it be to do with the 'locale.nl_langinfo' bieng
unavailable in xp?

Versions:
ActivePython 2.3.2 Build 232 (ActiveState Corp.) based
on Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC
v.1200 32 bit (Intel)] on win32
Windows XP Home Edition (up to dateish)

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

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

From noreply at sourceforge.net  Mon Feb 16 15:29:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 15:30:38 2004
Subject: [ python-Bugs-898253 ] strftime ignores date format on winxp
Message-ID: <E1AspMu-0003sm-00@sc8-sf-web2.sourceforge.net>

Bugs item #898253, was opened at 2004-02-17 09:19
Message generated for change (Comment added) made by matiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898253&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Sherborne (matiu)
Assigned to: Nobody/Anonymous (nobody)
Summary: strftime ignores date format on winxp

Initial Comment:
On Windows XP in the control panel set your country to
"New Zealand".

This gives a short date format of 'dd-mm-yy'

Now in python:
>>> from time import *
>>> print strftime('%c', localtime)
02/17/04 09:15:10
>>> print strftime('%x', localtime())
02/17/04

This is giving the date in the format 'mm-dd-yy'
(American).

Could it be to do with the 'locale.nl_langinfo' bieng
unavailable in xp?

Versions:
ActivePython 2.3.2 Build 232 (ActiveState Corp.) based
on Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC
v.1200 32 bit (Intel)] on win32
Windows XP Home Edition (up to dateish)

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

>Comment By: Matthew Sherborne (matiu)
Date: 2004-02-17 09:29

Message:
Logged In: YES 
user_id=304464

Sorry, code should be:

>>> from time import *
>>> print strftime('%c', localtime())
02/17/04 09:15:10
>>> print strftime('%x', localtime())
02/17/04

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

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

From noreply at sourceforge.net  Mon Feb 16 15:32:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 15:33:48 2004
Subject: [ python-Bugs-897625 ] time.strftime crashes python
Message-ID: <E1AspPv-00042F-00@sc8-sf-web2.sourceforge.net>

Bugs item #897625, was opened at 2004-02-16 10:33
Message generated for change (Comment added) made by matiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897625&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Tom Lynn (tlynn)
Assigned to: Brett Cannon (bcannon)
Summary: time.strftime crashes python

Initial Comment:
On Win2k:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Python dumps core.  Is that (ever) expected behaviour?

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-17 09:32

Message:
Logged In: YES 
user_id=304464

Also, please have a look at:
https://sourceforge.net/tracker/index.php?func=detail&aid=898253&group_id=5470&atid=105470

at the same time.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-16 14:23

Message:
Logged In: YES 
user_id=31435

I assume this is specific to Python on Windows using 
Microsoft's C, since this workalike plain C program also dies 
with a memory error while in the bowels of MS's strftime():

#include <stdio.h>
#include <time.h>

void main() {
    struct tm t;
    char buf[256];
    size_t i;

    t.tm_year = 1900 - 1900;
    t.tm_mon = 1 - 1;
    t.tm_mday = 1;
    t.tm_hour = 13;
    t.tm_min = 0;
    t.tm_sec = 0;
    t.tm_wday = -3;
    t.tm_yday = 0;
    t.tm_isdst = -1;

    printf("calling strftime\n");
    i = strftime(buf, sizeof(buf), "%a", &t);
    printf("i: %d\n", i);
}

The problem is the negative value for tm_wday.  MS strftime 
isn't defensive, and uses the negative tm_wday to index into 
nonsense memory.  Ironically, if C had defined the % operator 
in the sane way (meaning Python's way <wink>), a negative 
tm_wday wouldn't have survived for the C library function to 
see.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-16 12:41

Message:
Logged In: YES 
user_id=80475

It is expected.  Well, now that I've confirmed it on Py2.3.3
and Py2.4, yes ;-) 

Is it desirable?  Heck no.

Brett, can you take a look at this?

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

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

From noreply at sourceforge.net  Mon Feb 16 15:34:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 15:36:09 2004
Subject: [ python-Bugs-897625 ] time.strftime crashes python
Message-ID: <E1AspSC-0005pm-00@sc8-sf-web4.sourceforge.net>

Bugs item #897625, was opened at 2004-02-16 10:33
Message generated for change (Comment added) made by matiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897625&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Tom Lynn (tlynn)
Assigned to: Brett Cannon (bcannon)
Summary: time.strftime crashes python

Initial Comment:
On Win2k:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Python dumps core.  Is that (ever) expected behaviour?

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-17 09:34

Message:
Logged In: YES 
user_id=304464

On my linux system does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\x0e'

Python 2.3.3c1 (#2, Dec  6 2003, 16:44:56)
[GCC 3.3.3 20031203 (prerelease) (Debian)] on linux2

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-17 09:32

Message:
Logged In: YES 
user_id=304464

Also, please have a look at:
https://sourceforge.net/tracker/index.php?func=detail&aid=898253&group_id=5470&atid=105470

at the same time.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-16 14:23

Message:
Logged In: YES 
user_id=31435

I assume this is specific to Python on Windows using 
Microsoft's C, since this workalike plain C program also dies 
with a memory error while in the bowels of MS's strftime():

#include <stdio.h>
#include <time.h>

void main() {
    struct tm t;
    char buf[256];
    size_t i;

    t.tm_year = 1900 - 1900;
    t.tm_mon = 1 - 1;
    t.tm_mday = 1;
    t.tm_hour = 13;
    t.tm_min = 0;
    t.tm_sec = 0;
    t.tm_wday = -3;
    t.tm_yday = 0;
    t.tm_isdst = -1;

    printf("calling strftime\n");
    i = strftime(buf, sizeof(buf), "%a", &t);
    printf("i: %d\n", i);
}

The problem is the negative value for tm_wday.  MS strftime 
isn't defensive, and uses the negative tm_wday to index into 
nonsense memory.  Ironically, if C had defined the % operator 
in the sane way (meaning Python's way <wink>), a negative 
tm_wday wouldn't have survived for the C library function to 
see.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-16 12:41

Message:
Logged In: YES 
user_id=80475

It is expected.  Well, now that I've confirmed it on Py2.3.3
and Py2.4, yes ;-) 

Is it desirable?  Heck no.

Brett, can you take a look at this?

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

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

From noreply at sourceforge.net  Mon Feb 16 15:36:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 15:37:48 2004
Subject: [ python-Bugs-897625 ] time.strftime crashes python
Message-ID: <E1AspTq-0005tp-00@sc8-sf-web4.sourceforge.net>

Bugs item #897625, was opened at 2004-02-16 10:33
Message generated for change (Comment added) made by matiu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897625&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Tom Lynn (tlynn)
Assigned to: Brett Cannon (bcannon)
Summary: time.strftime crashes python

Initial Comment:
On Win2k:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Python dumps core.  Is that (ever) expected behaviour?

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-17 09:36

Message:
Logged In: YES 
user_id=304464

On WinXP Home does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\xfcI\xc1w\xf8I\xc1w\xf4I\xc1w\xf0I\xc1w\xecI\xc1w\xe8I\xc1w\xe4I\xc1w\xdcI\xc1w\xd4I\xc1w\xccI\xc1w\xc0I\xc1w\xb4I\xc1w\xacI\xc1w\xa0I\xc1w\x9cI\xc1w\x98I\xc1w\x94I\xc1w\x90I\xc1w\x8cI\xc1w\x88I\xc1w\x84I\xc1w\x80I\xc1w|I\xc1wxI\xc1wtI\xc1wpI\xc1whI\xc1w\I\xc1wTI\xc1wLI\xc1w\x8cI\xc1wDI\xc1w<I\xc1w4I\xc1w(I\xc1wI\xc1w\x14I\xc1w\x08I\xc1w\x04I\xc1w'

ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit
(Intel)] on win32


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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-17 09:34

Message:
Logged In: YES 
user_id=304464

On my linux system does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\x0e'

Python 2.3.3c1 (#2, Dec  6 2003, 16:44:56)
[GCC 3.3.3 20031203 (prerelease) (Debian)] on linux2

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-17 09:32

Message:
Logged In: YES 
user_id=304464

Also, please have a look at:
https://sourceforge.net/tracker/index.php?func=detail&aid=898253&group_id=5470&atid=105470

at the same time.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-16 14:23

Message:
Logged In: YES 
user_id=31435

I assume this is specific to Python on Windows using 
Microsoft's C, since this workalike plain C program also dies 
with a memory error while in the bowels of MS's strftime():

#include <stdio.h>
#include <time.h>

void main() {
    struct tm t;
    char buf[256];
    size_t i;

    t.tm_year = 1900 - 1900;
    t.tm_mon = 1 - 1;
    t.tm_mday = 1;
    t.tm_hour = 13;
    t.tm_min = 0;
    t.tm_sec = 0;
    t.tm_wday = -3;
    t.tm_yday = 0;
    t.tm_isdst = -1;

    printf("calling strftime\n");
    i = strftime(buf, sizeof(buf), "%a", &t);
    printf("i: %d\n", i);
}

The problem is the negative value for tm_wday.  MS strftime 
isn't defensive, and uses the negative tm_wday to index into 
nonsense memory.  Ironically, if C had defined the % operator 
in the sane way (meaning Python's way <wink>), a negative 
tm_wday wouldn't have survived for the C library function to 
see.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-16 12:41

Message:
Logged In: YES 
user_id=80475

It is expected.  Well, now that I've confirmed it on Py2.3.3
and Py2.4, yes ;-) 

Is it desirable?  Heck no.

Brett, can you take a look at this?

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

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

From noreply at sourceforge.net  Mon Feb 16 15:49:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 15:50:37 2004
Subject: [ python-Bugs-898271 ] symtable module crashes w/ coding declaration
Message-ID: <E1AspgF-0004zI-00@sc8-sf-web2.sourceforge.net>

Bugs item #898271, was opened at 2004-02-16 21:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898271&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter ?strand (astrand)
Assigned to: Nobody/Anonymous (nobody)
Summary: symtable module crashes w/ coding declaration

Initial Comment:
The symtable module doesn't work with source code
encodings, it seems. Sample code:

#!/usr/bin/env python
# -*- coding: iso-8859-1 -*-

import sys
import symtable
filename = sys.argv[0]
tab = symtable.symtable(open(filename).read(),
filename, exec")
print tab.get_type()

When running this code, I get:

Traceback (most recent call last):
  File "./bar.py", line 8, in ?
    print tab.get_type()
  File "/usr/local/lib/python2.3/symtable.py", line 71,
in get_type
    assert self._table.type in (1, 2, 3), AssertionError: unexpected type: 0

If I remove the source code encoding declaration,
things work fine. I've verified this problem with 2.3.2
and 2.3.3. 2.2.0 and 2.2.2 works fine. 

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

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

From noreply at sourceforge.net  Mon Feb 16 16:11:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 16:13:04 2004
Subject: [ python-Bugs-898271 ] symtable module crashes w/ coding declaration
Message-ID: <E1Asq1m-0006E1-00@sc8-sf-web2.sourceforge.net>

Bugs item #898271, was opened at 2004-02-16 21:49
Message generated for change (Settings changed) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898271&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter ?strand (astrand)
>Assigned to: Jeremy Hylton (jhylton)
Summary: symtable module crashes w/ coding declaration

Initial Comment:
The symtable module doesn't work with source code
encodings, it seems. Sample code:

#!/usr/bin/env python
# -*- coding: iso-8859-1 -*-

import sys
import symtable
filename = sys.argv[0]
tab = symtable.symtable(open(filename).read(),
filename, exec")
print tab.get_type()

When running this code, I get:

Traceback (most recent call last):
  File "./bar.py", line 8, in ?
    print tab.get_type()
  File "/usr/local/lib/python2.3/symtable.py", line 71,
in get_type
    assert self._table.type in (1, 2, 3), AssertionError: unexpected type: 0

If I remove the source code encoding declaration,
things work fine. I've verified this problem with 2.3.2
and 2.3.3. 2.2.0 and 2.2.2 works fine. 

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

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

From noreply at sourceforge.net  Mon Feb 16 16:19:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 16:22:46 2004
Subject: [ python-Bugs-898253 ] strftime ignores date format on winxp
Message-ID: <E1Asq9R-0000rT-00@sc8-sf-web1.sourceforge.net>

Bugs item #898253, was opened at 2004-02-16 15:19
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898253&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Sherborne (matiu)
>Assigned to: Brett Cannon (bcannon)
Summary: strftime ignores date format on winxp

Initial Comment:
On Windows XP in the control panel set your country to
"New Zealand".

This gives a short date format of 'dd-mm-yy'

Now in python:
>>> from time import *
>>> print strftime('%c', localtime)
02/17/04 09:15:10
>>> print strftime('%x', localtime())
02/17/04

This is giving the date in the format 'mm-dd-yy'
(American).

Could it be to do with the 'locale.nl_langinfo' bieng
unavailable in xp?

Versions:
ActivePython 2.3.2 Build 232 (ActiveState Corp.) based
on Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC
v.1200 32 bit (Intel)] on win32
Windows XP Home Edition (up to dateish)

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 15:29

Message:
Logged In: YES 
user_id=304464

Sorry, code should be:

>>> from time import *
>>> print strftime('%c', localtime())
02/17/04 09:15:10
>>> print strftime('%x', localtime())
02/17/04

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

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

From noreply at sourceforge.net  Mon Feb 16 16:42:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 16:43:24 2004
Subject: [ python-Bugs-897817 ] test_strptime failures on FC2-test
Message-ID: <E1AsqV7-00029R-00@sc8-sf-web1.sourceforge.net>

Bugs item #897817, was opened at 2004-02-16 00:52
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897817&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
>Assigned to: Brett Cannon (bcannon)
Summary: test_strptime failures on FC2-test

Initial Comment:
I'm seeing test_strptime failures on this box, running
a version of Fedora Core that's between 1 and the new
test release.

test test_strptime failed -- Traceback (most recent
call last): 
File "Lib/test/test_strptime.py", line 258, in
test_timezone
    self.failUnlessEqual(strp_output.tm_isdst, 0)
AssertionError: -1 != 0

Note that the following line (which tests GMT) also
fails with a -1.

The underlying failure:
>>> import _strptime
>>> strp_output = _strptime.strptime("UTC", "%Z")
>>> strp_output.tm_isdst
-1
>>> strp_output = _strptime.strptime("GMT", "%Z")
>>> strp_output.tm_isdst
-1


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

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

From noreply at sourceforge.net  Mon Feb 16 18:44:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 18:45:42 2004
Subject: [ python-Bugs-858016 ] Pathological case segmentation fault in
	issubclass
Message-ID: <E1AssPb-00078d-00@sc8-sf-web4.sourceforge.net>

Bugs item #858016, was opened at 2003-12-10 22:13
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Eric M. Hopper (omnifarious)
>Assigned to: Brett Cannon (bcannon)
Summary: Pathological case segmentation fault in issubclass

Initial Comment:
This works for the PowerPC Python compiled with gcc 3.3
on OS X using fink.  I suspect it's broader based than
that, but I don't have the ability to check properly.

Here's how to make it segment fault:

x = (basestring,)
for i in xrange(0, 1000000):
   x = (x,)
issubclass(str, x)

At least, it segment faults at the interactive prompt
this way.  I don't know if it does when it's executed
from a file.


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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-16 18:44

Message:
Logged In: YES 
user_id=31435

Well, that wasn't as much fun for you as I hoped -- the 
report just sat there until I got a free holiday <wink>.  Marked 
Accepted and back to you -- looks good!

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

Comment By: Brett Cannon (bcannon)
Date: 2003-12-19 00:24

Message:
Logged In: YES 
user_id=357491

OK, Tim, start hopping.  =)

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

Comment By: Tim Peters (tim_one)
Date: 2003-12-18 16:48

Message:
Logged In: YES 
user_id=31435

Oh, Brett, you're missing a chance for some fun here!  A bug 
should always be assigned to the next person who should "do 
something" about it.  Think of it as a hot potato.  You should 
assign the bug to who you *want* to review this, and then 
sit back and watch the fun, as each person in turn tries to 
unload the potato onto someone else.  That's one way to get 
a comforting illusion of activity here <wink>.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-12-18 16:39

Message:
Logged In: YES 
user_id=357491

I have appended a file that adds a basic test to make sure that 
when the items of a tuple are used to call isinstance or issubclass 
that only classes or types are used; everything else raises 
TypeError.  Also tried to clarify the wording of the doc strings.  
Changed the docs for isinstance since it allowed nested tupling 
while issubclass' didn't.

Have a look and if someone will sign off on it I will apply the patch 
and then start working on a 2.3 solution that doesn't break 
semantics.

And I just realized I left out a Misc/NEWS in the patch; it will be 
there when it gets applied.

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

Comment By: Tim Peters (tim_one)
Date: 2003-12-14 16:09

Message:
Logged In: YES 
user_id=31435

I'm afraid that changing semantics needs to be run through 
the python-dev wringer first -- "shouldn't break very much 
code" isn't "shouldn't break any code".  The *comments* in 
these functions make it appear that they never intended to 
support the OP's original code snippet, but the docs don't 
match.  This leaves the intent a mystery, so it needs to be 
discussed.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-12-14 15:55

Message:
Logged In: YES 
user_id=357491

OK, consider my worldview fixed.  =)

I will add a check in the tuple unpacking 'for' loop to make sure it 
is only passing issubclass classes and not more tuples.  Simple 
and shouldn't break very much code.  Otherwise the code would 
have to keep a count and extra bookkeeping and it would get 
messy quickly.

And I will take a look at isinstance, although this tuple feature was 
added in 2.3 for issubclass so it might not be an issue.

And I will backport it.

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

Comment By: Tim Peters (tim_one)
Date: 2003-12-13 20:08

Message:
Logged In: YES 
user_id=31435

Yes, this needs to be fixed if it *can* be fixed without heroic 
effort or insane slowdown.  Looks like it can be.

Brett, the missing piece of your worldview <wink> here is that 
anywhere Python can be tricked into segfaulting is a kind 
of "security hole" -- it's not just mistakes we want to protect 
programmers from, we also want to bulletproof against hostile 
users, to the extent sanely possible.

BTW, if issubclass() has this insecurity, I bet isinstance() 
does too (they were introduced & coded at the same time).

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

Comment By: Eric M. Hopper (omnifarious)
Date: 2003-12-11 12:54

Message:
Logged In: YES 
user_id=313

Well, I think any case where the system segment faults
unexpectedly is bad, regardless of how pathological it is.

Personally, I think that issubclass should either have a
recursion limit after which it throws an exception, or it
shouldn't go into sub-tuples at all.

The reason I made this test is that I read the description
of the behavior of issublcass and found it rather strange,
so I decided to push it to see how far it would go.


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

Comment By: Brett Cannon (bcannon)
Date: 2003-12-10 23:28

Message:
Logged In: YES 
user_id=357491

If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you 
will notice that PyObject_IsSubclass goes into a 'for' loop for each 
item in the tuple passed in and calls PyObject_IsSubclass .  
Unfortunately it makes no check for whether the argument it is 
passing is a class itself or not.  This allows it to keep making calls 
as long as the second argument is either a class or a tuple.  This 
is what is leads to the stack being blown and the subsequent 
segfault.

Obvious solution is to put in a check that the argument about to be 
passed is a class itself so as to not have such a deep call chain.  
But since ``help(issubclass)`` actually makes the above use legit 
(it says using a tuple as a second argument is equivalent as 
passing each item to issubclass which is what it is doing, albeit in 
a rather uncommon and pointless way), is it worth putting the 
check in?  Since this is such an obvious mis-use, I say no.  But if 
someone else on python-dev steps in and says otherwise I will 
patch it.

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

Comment By: Eric M. Hopper (omnifarious)
Date: 2003-12-10 22:16

Message:
Logged In: YES 
user_id=313

I forgot this:

Python 2.3.2 (#1, Dec  4 2003, 09:13:58) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.


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

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

From noreply at sourceforge.net  Mon Feb 16 18:52:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 18:53:59 2004
Subject: [ python-Bugs-810879 ] shutil.copyfile fails when dst exists
	read-only
Message-ID: <E1AssXf-0000zc-00@sc8-sf-web1.sourceforge.net>

Bugs item #810879, was opened at 2003-09-22 19:21
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810879&group_id=5470

Category: Windows
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ray Pasco (pascor)
>Assigned to: A.M. Kuchling (akuchling)
Summary: shutil.copyfile fails when dst exists read-only

Initial Comment:
(WIN32):  shutil.copyfile fails when the dst file already 
exists, but in read-only mode.  As the old file is
about to be
clobbered, a fix I've been using is to delete the
orginal file
first.   The attached my be inelegant, but works fine




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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-16 18:52

Message:
Logged In: YES 
user_id=31435

Andrew, what does this do on Unix?  I don't *want* copyfile() 
to clobber read-only files, so I view this report as a small lack 
in the docs (which unconditionally say dst will be replaced).  
If the user lacks sufficient write permissions on Unix (a decent 
approximation to Windows "read only" state), does copyfile() 
succeed anyway?  I sure hope not.  On Windows,

    fdst = open(dst, 'wb')

dies with a (thoroughly appropriate, according to me)

    IOError: [Errno 13] Permission denied: <dst_value>

when dst is read-only.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2003-09-25 14:37

Message:
Logged In: YES 
user_id=11375

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

Please try again.

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

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

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

From noreply at sourceforge.net  Mon Feb 16 18:54:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 18:55:51 2004
Subject: [ python-Bugs-781614 ] Windows _bsddb link warnings
Message-ID: <E1AssZS-00014Z-00@sc8-sf-web1.sourceforge.net>

Bugs item #781614, was opened at 2003-08-01 13:04
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Dunn (robind)
>Assigned to: Thomas Heller (theller)
Summary: Windows _bsddb link warnings

Initial Comment:
Hi,

The PCbuild/readme.txt says this:

'''
    XXX We're actually linking against
Release_static\libdb41s.lib.
    XXX This yields the following warnings:
"""
Compiling...
_bsddb.c
Linking...
   Creating library ./_bsddb.lib and object ./_bsddb.exp
LINK : warning LNK4049: locally defined symbol
"_malloc" imported
LINK : warning LNK4049: locally defined symbol "_free"
imported
LINK : warning LNK4049: locally defined symbol
"_fclose" imported
LINK : warning LNK4049: locally defined symbol "_fopen"
imported
_bsddb.pyd - 0 error(s), 4 warning(s)
"""
    XXX This isn't encouraging, but I don't know what
to do about it.
'''

The cause of this is the fact that libdb41s.lib is
built with the flags for using the "Multithreaded" C
RTL but Python uses the "MUltithreaded DLL" C RTL.  In
other words, libdb is specifying that the C RTL should
be linked statically but Python wants to link to it
statically. 

To avoid these warnings the instructions can be changed
to specify that the builder should change the flags in
the Berkeley_DB project.  Also you should probably link
with the Debug_static\libdb41sd.lib when building the
debug version of Python.


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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-16 18:54

Message:
Logged In: YES 
user_id=31435

Thomas, you have any insight into this one?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-08-01 15:50

Message:
Logged In: YES 
user_id=21627

Can you propose a specific patch?

Also, it would be preferable if changing the source code of
the Sleepycat distribution would not be necessary.

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

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

From noreply at sourceforge.net  Mon Feb 16 19:06:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 19:07:28 2004
Subject: [ python-Bugs-586899 ] email package does not work with mailbox
Message-ID: <E1Asskn-0005ux-00@sc8-sf-web3.sourceforge.net>

Bugs item #586899, was opened at 2002-07-26 05:19
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586899&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email package does not work with mailbox

Initial Comment:
The email.message_from_file function does not seem to 
work correctly when used as the "factory" argument to 
the mailbox.UnixMailbox function. The "From_" 
separator line gets included in the preceding mail 
message.

For a demonstration of this, see the attached zip file. 
The Python code loads the first message in the mailbox 
file and then displays the final line. This shows the 
From_ line from the subsequent message (correctly 
quoted with a ">"!!!).

This is with Python 2.2 on Windows 2000. The Python 
banner line is

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32

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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-16 19:06

Message:
Logged In: YES 
user_id=31435

Sorry for the delay.  Paul is certainly correct that the only 
thing you can reliably do with a tell() result from a file opened 
in text mode is seek() to it later.  Arithmetic on tell() results 
makes no sense for text-mode files.  That's ANSI C rules, and 
they matter on Windows.

Since we're going on two years without a patch here, sounds 
like changing the docs is better than nothing.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-03-10 12:05

Message:
Logged In: YES 
user_id=12800

Since this makes no difference for *nix and I don't have a
Windows box to play with, I'm assigning to Tim.  He can
thank me later. 

Paul's explanation seems reasonable, but without a patch, I
doubt any of us have motivation to fix it.  I'd be happy
with a documentation change.

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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-07-26 11:59

Message:
Logged In: YES 
user_id=12800

I don't have time to comment except to say that
email.message_from_file() definitely works as the factory
function for mailbox.UnixMailbox.  As proof, I have the
following code in Mailman:

class Mailbox(mailbox.PortableUnixMailbox):
    def __init__(self, fp):
        mailbox.PortableUnixMailbox.__init__(self, fp,
email.message_from_file)

so I know it works. :)

I'll look at the comments Paul's made when I get a chance. 
I'm assigning this bug report to me.

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

Comment By: Paul Moore (pmoore)
Date: 2002-07-26 10:06

Message:
Logged In: YES 
user_id=113328

This is a text vs binary file issue with the mailbox module, not 
with email. The "fp" parameter to the [Portable]UnixMailbox 
class must be opened in binary mode, or incorrect results are 
obtained.

This is caused by the implementation of _Subfile.read() in 
mailbox.py, which assumes that number of characters read is 
the same as the difference between tell() values, an 
assumption which fails for text mode files on Windows.

I would consider this behaviour a bug, and would prefer it to 
be fixed. However, if it is not to be fixed, the documentation 
should be changed to note that the "fp" parameter for the 
mailbox constructor must be opened in binary mode.

For MMDF and Babyl format mailboxes, it's arguably correct, 
as the file format is binary. For Unix mailboxes, the file is text 
format, so opening the file in text mode is not unreasonable.

Question: is the universal newline support in Python 2.3 going 
to mess this up further?

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

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

From noreply at sourceforge.net  Mon Feb 16 19:22:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 19:23:16 2004
Subject: [ python-Bugs-789290 ] Minor FP bug in object.c
Message-ID: <E1Ast04-0006YM-00@sc8-sf-web3.sourceforge.net>

Bugs item #789290, was opened at 2003-08-15 11:15
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789290&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm1)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Minor FP bug in object.c

Initial Comment:
This is closely related to the one I have reported
in floatobject.c (789159).  VERY closely.  It is
shown up by the following test on a machine with
64-bit longs and floating-point trapping turned on
(though it might show up as bogus results even with
no trapping):

print int( 9223372036854775200.0)
print int( 9223372036854775800.0)
print int(-9223372036854776800.0)
print int(-9223372036854777000.0)

958,959c958,959
<       double intpart, fractpart;
<       int expo;
---
>       double intpart, fractpart, z;
>       int expo, i, j;
978c978,989
<               if (intpart > LONG_MAX || -intpart >
LONG_MAX) {
---
>               /* Remember that (double)LONG_MAX can
round either way. */
>               if (intpart > LONG_MIN/2 && intpart <
LONG_MAX/2)
>                       z = 0.0;
>               else {
>                       z = (intpart >= 0.0 ? intpart :
-intpart);
>                       for (i =
(sizeof(long)*CHAR_BIT-1)/16; i >= 0; --i) {
>                               x = LONG_MAX;
>                               for (j = 0; j < i; ++j)
x >>= 16;
>                               z -=
ldexp(x&0xffff,16*i);
>                       }
>               }
>               if (z > 0.0) {


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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-16 19:22

Message:
Logged In: YES 
user_id=31435

Sorry, I can't make for this, so unassigned it.

To help the next person,

1. Please say something about what "the bug" is.  You show 4 
lines printing int(big_integer), but don't show any output.  In 
addition, the patch *appears* to be against _Py_HashDouble
(), but that function isn't involved in int() or in printing.

2. Please generate a context diff for patches, and attach the 
patch to the bug report instead of pasting it into the text 
box.  SourceForge destroys the intended line structure and 
indentation in text boxes, and this non-context diff patch is 
very hard to follow in this mangled form.

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

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

From noreply at sourceforge.net  Mon Feb 16 19:51:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 19:52:55 2004
Subject: [ python-Bugs-890010 ] Odd warning behaviors
Message-ID: <E1AstSU-0000Rg-00@sc8-sf-web2.sourceforge.net>

Bugs item #890010, was opened at 2004-02-03 17:25
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Odd warning behaviors

Initial Comment:
This is from Evan Simpson, on the zope-dev list.  The 
bulk have to do with what happens if __name__ is set to 
None:


Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python 
2.3.3 problem
http://mail.zope.org/mailman/listinfo/zope-dev

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> range(1.0)
__main__:1: DeprecationWarning: integer argument 
expected, got float
[0]
 >>>

So far, so good.  However:

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> __name__=None
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 63, in 
warn_explicit
     if module[-3:].lower() == ".py":
TypeError: unsubscriptable object
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import warnings
 >>> warnings.simplefilter("error", 
category=DeprecationWarning)
 >>> range(1.0)
[]
 >>> 1+1
Traceback (most recent call last):
   File "/usr/lib/python2.3/warnings.py", line 57, in warn
     warn_explicit(message, category, filename, lineno, 
module, registry)
   File "/usr/lib/python2.3/warnings.py", line 92, in 
warn_explicit
     raise message
DeprecationWarning: integer argument expected, got 
float
 >>>

...and...

Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
 >>> import pdb
 >>> __name__ = None
 >>> pdb.run('range(1.0)')
 > <string>(1)?()
(Pdb) s
--Call--
 > /usr/lib/python2.3/warnings.py(24)warn()
-> def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning: 
tp_compare didn't return 
-1 or -2 for exception
   i = max(0, len(stack) - 1)
[traceback snipped]

Looks like something isn't properly propagating 
exceptions.

Cheers,

Evan @ 4-am


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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-16 19:51

Message:
Logged In: YES 
user_id=31435

I'm listening, but with half of part of one ear.  Have to agree 
convertsimple() was wrong in these cases, but can't make 
time for more than that.  Reassigned to Jeremy, partly at 
random (his is one of the names that shows up as a recent 
getargs.c changer).

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-12 09:09

Message:
Logged In: YES 
user_id=6656

Is anyone listening?

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 10:05

Message:
Logged In: YES 
user_id=6656

Oops, wrong file.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 10:03

Message:
Logged In: YES 
user_id=6656

How's this?  It's horrible, but I'm not sure that can be avoided.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 08:22

Message:
Logged In: YES 
user_id=6656

OK, the problem is that returning NULL from 
getargs.c:convertsimple indicates *success* (argh!).

Fixing that provokes weird errors from handle_range_longs.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-04 07:10

Message:
Logged In: YES 
user_id=6656

Might this be specific to range()?

[mwh@pc150 build]$ ./python.exe -Werror
Python 2.4a0 (#3, Feb  3 2004, 19:23:25) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> range(5.0)
[]

range()'s argument handling is somewhat odd

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

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

From noreply at sourceforge.net  Mon Feb 16 19:56:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 19:57:51 2004
Subject: [ python-Bugs-853800 ] No documentation for zipimport module
Message-ID: <E1AstXP-0000fY-00@sc8-sf-web2.sourceforge.net>

Bugs item #853800, was opened at 2003-12-04 16:35
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853800&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: No documentation for zipimport module

Initial Comment:
It doesn't appear that the zipimport module is 
documented in Python 2.3.2, apart from a note in 
the "what's new in Python 2.3" section.  It should really 
be in the list of all standard modules.

Presumably the help(zipimport) contents could form the 
basis of this documentation.  I'd be willing to put a 
patch together for this if someone gives me clear 
guidelines about what should be there.

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

>Comment By: Tony Meyer (anadelonbrin)
Date: 2004-02-17 13:56

Message:
Logged In: YES 
user_id=552329

Well, it's been two months (setting up latex2html on cygwin 
isn't easy! <wink>), but here's something.

Attached is a draft module doc for zipimport, and a diff to add 
it to the library (I wasn't really sure where it belonged, so this 
diff might be no good it's only one line, anyway).

The documentation is a combination of the docstrings, stuff 
from the PEP, and stuff from the "what's new in 2.3" page.  
Hope it's ok.

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

Comment By: Just van Rossum (jvr)
Date: 2003-12-08 06:55

Message:
Logged In: YES 
user_id=92689

The doc strings should indeed be a good start. See also http://
python.org/peps/pep-0273.html and http://python.org/peps/pep-
0302.html for way more details than neccesary for the docs. Feel 
free to concact me off line if you have more questions; your offer 
is most welcome!

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

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

From noreply at sourceforge.net  Mon Feb 16 21:44:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 16 21:45:52 2004
Subject: [ python-Bugs-853800 ] No documentation for zipimport module
Message-ID: <E1AsvDw-00052A-00@sc8-sf-web2.sourceforge.net>

Bugs item #853800, was opened at 2003-12-04 16:35
Message generated for change (Comment added) made by anadelonbrin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853800&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: No documentation for zipimport module

Initial Comment:
It doesn't appear that the zipimport module is 
documented in Python 2.3.2, apart from a note in 
the "what's new in Python 2.3" section.  It should really 
be in the list of all standard modules.

Presumably the help(zipimport) contents could form the 
basis of this documentation.  I'd be willing to put a 
patch together for this if someone gives me clear 
guidelines about what should be there.

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

>Comment By: Tony Meyer (anadelonbrin)
Date: 2004-02-17 15:44

Message:
Logged In: YES 
user_id=552329

New version with correct PEP references.

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

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-02-17 13:56

Message:
Logged In: YES 
user_id=552329

Well, it's been two months (setting up latex2html on cygwin 
isn't easy! <wink>), but here's something.

Attached is a draft module doc for zipimport, and a diff to add 
it to the library (I wasn't really sure where it belonged, so this 
diff might be no good it's only one line, anyway).

The documentation is a combination of the docstrings, stuff 
from the PEP, and stuff from the "what's new in 2.3" page.  
Hope it's ok.

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

Comment By: Just van Rossum (jvr)
Date: 2003-12-08 06:55

Message:
Logged In: YES 
user_id=92689

The doc strings should indeed be a good start. See also http://
python.org/peps/pep-0273.html and http://python.org/peps/pep-
0302.html for way more details than neccesary for the docs. Feel 
free to concact me off line if you have more questions; your offer 
is most welcome!

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

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

From noreply at sourceforge.net  Mon Feb 16 23:59:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 00:00:28 2004
Subject: [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E1AsxK9-0004Mu-00@sc8-sf-web1.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 03:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Brett Cannon (bcannon)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: 'NoneType' object is not callable


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-02-16 20:59

Message:
Logged In: YES 
user_id=357491

Does anyone know how to cause this error in isolation?  I have tried a 
bunch of different ways but cannot cause an exception to be raised at the 
correct point in Threading.__bootstrap() to lead to self.__stop() to be 
called while the interpreter is tearing itself down.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-09 17:18

Message:
Logged In: YES 
user_id=357491

After staring at the code, I am not even sure if the calls for its side-
effect are needed.  If you call currentThread(), it either returns a value 
from _active which is a dict of running Thread instances indexed by 
thread idents, or a new _DummyThread instance that inserts itself into 
_active.  Now the two calls in the _Condition class are purely for this 
possible side-effect.

And yet at no point is anything from _active, through currentThread or 
direct access, even touched by a _Condition method.  The only chance 
this might be an issue is if a _Condition instance uses an RLock instance 
for its locking, which is the default behavior.

But this still makes the side-effect need useless.  RLocks will call 
currentThread on their own and since this is all in the same thread the 
result won't change.  And in this specific case of this bug, the _Condition 
instance is created with a Lock instance since that is what the Thread 
instance uses for constructing the _Condition instance it use, which is just 
thread.allocate_lock() which is obviously not an RLock.

In other words I can't find the point to the side-effect in _Condition.  I 
will try to come up with some testing code that reproduces the error and 
then see if just removing the calls in _Condition remove the error and 
still pass the regression tests.

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

Comment By: John Goerzen (jgoerzen)
Date: 2003-06-16 06:26

Message:
Logged In: YES 
user_id=491567

I can confirm that this behavior is not present in Python 2.2 in 
the same version that I am using to test against Python 2.3. 
 
I will be on vacation for most of this and next week.  I'll try to 
get to the logging script before I leave, but I might not get to it 
until I return. 
 
FYI, you can also obtain OfflineIMAP at 
http://quux.org/devel/offlineimap. 
 
 

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:58

Message:
Logged In: YES 
user_id=357491

OK, following Tim's advice I checked and it seems that Thread 
calls a method while shutting itself down that calls 
Condition.notifyAll which calls currentThread which is a global.  It 
would appear that offlineimap is leaving its threads running, the 
program gets shut down, the threads raise an error while 
shutting down (probably because things are being torn down), 
this triggers the stopping method in Thread, and this raises its 
own exception because of the teardown which is what we are 
seeing as the TypeError.

So the question is whether Condition should store a local 
reference to currentThread or not.  It is not the most pure 
solution since this shutdown issue is not Condition's, but the only 
other solution I can think of is to have Thread keep a reference 
to currentThread, inject it into the current frame's global 
namespace, call Condition.notifyAll, and then remove the 
reference from the frame again.  I vote for the cleaner, less pure 
solution.  =)

Am I insane on this or does it at least sound like this is the 
problem and proper solution?

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:19

Message:
Logged In: YES 
user_id=357491

Nuts.  For some reason I thought the OP had said when threads 
were exiting.

I will ask on python-dev for a good explanation of what happens 
when Python is shutting down.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-15 18:05

Message:
Logged In: YES 
user_id=31435

Note that the OP said "when my application exits".  When 
Python is tearing down the universe, it systematically sets 
module-global bindings to None.  currentThread() is a module 
global.  I can't make more time for this now, so for more info 
talk about it on Python-Dev.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 16:44

Message:
Logged In: YES 
user_id=357491

Well, I'm stumped.  I checked the diff from when 2.2 was initially 
released until now and the only change that seems to be related 
to any of this is that what is returned by currentThread is not 
saved in a variable.  But since the error is the calling of 
currentThread itself and not saving the return value I don't see 
how that would affect anything.

I also went through offlineimap but I didn't see anything there 
that seemed to be setting currentThread to None.  Although 
since several files do ``import *`` so there still is a possibility of 
overwriting currentThread locally.

So, for my owning learning and to help solve this, I have written 
a tracing function that writes to stderr using the logging package 
when it detects that either currentThread or 
threading.currentThread has been set to None, locally or globally 
(I assume the code is not injecting into builtins so I didn't bother 
checking there).  The file is named tracer.py and I have attached 
it to this bug report.  If you can execute 
``sys.settrace(tracer.trace_currentThread)`` before offlinemap 
starts executing and immediately within each thread (it has to be 
called in *every* thread since tracing functions are no inherited 
from the main thread) it should print out a message when 
currentThread becomes None.  If you *really* want to make this 
robust you can also have it check sys.modules['threading'] every 
time as well, but I figure there is not going to be much renaming 
and masking of currentThread.

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

Comment By: Matthias Klose (doko)
Date: 2003-06-15 01:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 01:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

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

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

From noreply at sourceforge.net  Tue Feb 17 00:04:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 00:05:51 2004
Subject: [ python-Bugs-791542 ] test_threading
Message-ID: <E1AsxPU-0004W7-00@sc8-sf-web1.sourceforge.net>

Bugs item #791542, was opened at 2003-08-19 14:32
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791542&group_id=5470

Category: Build
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Shawn Leard (sleard1)
>Assigned to: Brett Cannon (bcannon)
Summary: test_threading

Initial Comment:

Due the problems reported with version 2.3 I thought I
would give version 2.2.3 a shot. The problem I am
having here is no matter what switches I pass configure
to disable threading it still tries to test them and as
a result the make test fails.

168 tests OK.
1 test failed:
    test_threading
24 tests skipped:
    test_al test_asynchat test_bsddb test_cd test_cl
test_curses
    test_dl test_email_codecs test_fork1 test_gl
test_imgfile
    test_linuxaudiodev test_minidom test_openpty
test_pyexpat
    test_queue test_sax test_socket_ssl
test_socketserver test_thread
    test_threaded_import test_threadedtempfile test_winreg
    test_winsound

--------

./configure --prefix=/usr/local --with-gnu-ld
--with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld
--enable-nls   --with-included-gettext --with-fpectl
--with-threads=no --without-threads --disable-threads
--with-gnu-as

--------

mars$ /files/local/src/Python-2.2.3/python
test_threading.py
Traceback (most recent call last):
  File "test_threading.py", line 7, in ?
    import threading
  File
"/files/local/src/Python-2.2.3/Lib/threading.py", line
5, in ?
    import thread
ImportError: No module named thread


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

Comment By: Shawn Leard (sleard1)
Date: 2003-09-08 13:00

Message:
Logged In: YES 
user_id=328879



I will give this a shot and get back to you.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-09-04 18:53

Message:
Logged In: YES 
user_id=357491

In order to better debug this, can you state what the line says 
when test_threading fails; e.g., "test_sunaudiodev skipped -- ..."?

The test will be run regardless of whether you compiled with 
threads or not, but it should be listed as a skip instead of a 
failure.

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

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

From noreply at sourceforge.net  Tue Feb 17 00:08:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 00:09:32 2004
Subject: [ python-Bugs-873652 ] Platform module not documented
Message-ID: <E1AsxT3-0004dg-00@sc8-sf-web1.sourceforge.net>

Bugs item #873652, was opened at 2004-01-09 01:40
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=873652&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Brunning (brunns)
>Assigned to: Brett Cannon (bcannon)
Summary: Platform module not documented

Initial Comment:
The platform module isn't mentioned in the standard
ducumentation, so far as I can see, though the
doc-strings look pretty good.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-01-09 22:10

Message:
Logged In: YES 
user_id=357491

The LaTeX docs are in 2.4 .  They have not been backported to 2.3 
.

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

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

From noreply at sourceforge.net  Tue Feb 17 00:45:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 00:47:03 2004
Subject: [ python-Feature Requests-889544 ] win32 raw socket support
Message-ID: <E1Asy3I-0002ss-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #889544, was opened at 2004-02-03 08:15
Message generated for change (Settings changed) made by jesko-rs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=889544&group_id=5470

>Category: Python Library
Group: None
Status: Open
Resolution: Works For Me
>Priority: 7
Submitted By: Jesko Huettenhain (jesko-rs)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32 raw socket support

Initial Comment:
I already programmed several tools in Windows that 
make use of raw sockets as Windows NT 5.0 and later 
OS (those include 2k and XP) support raw sockets in the 
Winsock 2 API. I used C/C++ for programming them 
mainly, but I figured python had the better builtin tools 
for building custom packets. However, I witnessed 
several problems when trying to create and use raw 
sockets in Python (Version 2.3, Windows interpreter): 
The raw socket was created, but the IP_HDRINCL 
option, for instance, could not be set once the socket 
was bound. This one and similar problems were indicating 
that the raw sockets implementation was either 
unavailable or had some strange bug.

After I had tried to find the problem in socketmodule.c 
for a while, I realized the problem was not the code, it 
was the library that had been linked with _socket.pyd. It 
looks like _socket.pyd links to wsock32.dll by default, 
which is the DLL that implements Winsock 1 for 32-bit 
windows. However, it should link to ws2_32.dll to provide 
access to the more up-to-date Winsock 2 API. The fix I 
suggest is fairly simple. The key is the WSAStartup() 
function which will let you use the Winsock2 API if it is 
available or use Winsock1 if Winsock2 is not available. 
For this purpose, I link using ws2_32.lib as recommended 
by MSDN and call WSAStartup() by requesting a Winsock 
Version of 2.0. MSDN says that if Winsock 2.0 is 
unavailable, the call will succeed and the Winsock 1 DLL 
will be used.

This fix works pretty well on my Windows 2k machine - I 
am unfortunately not able to test it on other machines 
as well. While messing with the problem, I got a lot of 
help from Matt Cowles [matt@mondoinfo.com] and he 
also suggested that I should post this request here, so 
that's what I am doing.

by_the_way:
As I was already messing with the _socket.pyd dll 
directly, I also added a new member function for python 
sockets called ioctl() to manually ioctl() the socket. 
Moreover, I added the integer constants IP_HDRINCL 
and SIO_RCVALL to be defined always, so that this code 
works and provides pretty satisfying results on my Win2k 
box (a simple sniffer):

from socket import *
s = socket(AF_INET,SOCK_RAW,IPPROTO_RAW)
s.bind((gethostbyname(gethostname()),0))
s.setsockopt(IPPROTO_IP,IP_HDRINCL,1)
s.ioctl(SIO_RCVALL,1)
while(1): print s.recvfrom(4000)[0],"\n------------"

The files I changed (including socket.py with the new 
ioctl function) can be found at:

http://rs.fromadia.com/pysockraw/

It would be very kind if the next version of the Python 
interpreter for windows would include this feature by 
default as it would allow developers like me to build 
python tools that make use of raw sockets in 
Windows ... I can see not many developers are 
interested in this particular feature, but more support is 
better than less support.


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

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

From noreply at sourceforge.net  Tue Feb 17 08:51:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 08:52:40 2004
Subject: [ python-Bugs-791542 ] test_threading
Message-ID: <E1At5d9-00064r-00@sc8-sf-web1.sourceforge.net>

Bugs item #791542, was opened at 2003-08-19 17:32
Message generated for change (Comment added) made by sleard1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791542&group_id=5470

Category: Build
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Shawn Leard (sleard1)
Assigned to: Brett Cannon (bcannon)
Summary: test_threading

Initial Comment:

Due the problems reported with version 2.3 I thought I
would give version 2.2.3 a shot. The problem I am
having here is no matter what switches I pass configure
to disable threading it still tries to test them and as
a result the make test fails.

168 tests OK.
1 test failed:
    test_threading
24 tests skipped:
    test_al test_asynchat test_bsddb test_cd test_cl
test_curses
    test_dl test_email_codecs test_fork1 test_gl
test_imgfile
    test_linuxaudiodev test_minidom test_openpty
test_pyexpat
    test_queue test_sax test_socket_ssl
test_socketserver test_thread
    test_threaded_import test_threadedtempfile test_winreg
    test_winsound

--------

./configure --prefix=/usr/local --with-gnu-ld
--with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld
--enable-nls   --with-included-gettext --with-fpectl
--with-threads=no --without-threads --disable-threads
--with-gnu-as

--------

mars$ /files/local/src/Python-2.2.3/python
test_threading.py
Traceback (most recent call last):
  File "test_threading.py", line 7, in ?
    import threading
  File
"/files/local/src/Python-2.2.3/Lib/threading.py", line
5, in ?
    import thread
ImportError: No module named thread


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

>Comment By: Shawn Leard (sleard1)
Date: 2004-02-17 08:51

Message:
Logged In: YES 
user_id=328879



Brett,

I am going to close this because the box I had was
redeployed and I have no longer had this problem.

Best Regards,

Shawn


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

Comment By: Shawn Leard (sleard1)
Date: 2003-09-08 16:00

Message:
Logged In: YES 
user_id=328879



I will give this a shot and get back to you.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-09-04 21:53

Message:
Logged In: YES 
user_id=357491

In order to better debug this, can you state what the line says 
when test_threading fails; e.g., "test_sunaudiodev skipped -- ..."?

The test will be run regardless of whether you compiled with 
threads or not, but it should be listed as a skip instead of a 
failure.

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

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

From noreply at sourceforge.net  Tue Feb 17 08:53:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 09:03:17 2004
Subject: [ python-Bugs-791542 ] test_threading
Message-ID: <E1At5er-0006Bo-00@sc8-sf-web1.sourceforge.net>

Bugs item #791542, was opened at 2003-08-19 17:32
Message generated for change (Settings changed) made by sleard1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791542&group_id=5470

Category: Build
Group: Python 2.2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Shawn Leard (sleard1)
Assigned to: Brett Cannon (bcannon)
Summary: test_threading

Initial Comment:

Due the problems reported with version 2.3 I thought I
would give version 2.2.3 a shot. The problem I am
having here is no matter what switches I pass configure
to disable threading it still tries to test them and as
a result the make test fails.

168 tests OK.
1 test failed:
    test_threading
24 tests skipped:
    test_al test_asynchat test_bsddb test_cd test_cl
test_curses
    test_dl test_email_codecs test_fork1 test_gl
test_imgfile
    test_linuxaudiodev test_minidom test_openpty
test_pyexpat
    test_queue test_sax test_socket_ssl
test_socketserver test_thread
    test_threaded_import test_threadedtempfile test_winreg
    test_winsound

--------

./configure --prefix=/usr/local --with-gnu-ld
--with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld
--enable-nls   --with-included-gettext --with-fpectl
--with-threads=no --without-threads --disable-threads
--with-gnu-as

--------

mars$ /files/local/src/Python-2.2.3/python
test_threading.py
Traceback (most recent call last):
  File "test_threading.py", line 7, in ?
    import threading
  File
"/files/local/src/Python-2.2.3/Lib/threading.py", line
5, in ?
    import thread
ImportError: No module named thread


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

Comment By: Shawn Leard (sleard1)
Date: 2004-02-17 08:51

Message:
Logged In: YES 
user_id=328879



Brett,

I am going to close this because the box I had was
redeployed and I have no longer had this problem.

Best Regards,

Shawn


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

Comment By: Shawn Leard (sleard1)
Date: 2003-09-08 16:00

Message:
Logged In: YES 
user_id=328879



I will give this a shot and get back to you.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-09-04 21:53

Message:
Logged In: YES 
user_id=357491

In order to better debug this, can you state what the line says 
when test_threading fails; e.g., "test_sunaudiodev skipped -- ..."?

The test will be run regardless of whether you compiled with 
threads or not, but it should be listed as a skip instead of a 
failure.

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

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

From noreply at sourceforge.net  Tue Feb 17 09:36:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 09:37:40 2004
Subject: [ python-Bugs-898757 ] Python 2.3 encoding parsing bug
Message-ID: <E1At6Kr-0005Gy-00@sc8-sf-web3.sourceforge.net>

Bugs item #898757, was opened at 2004-02-17 14:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898757&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward K. Ream (edream)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3 encoding parsing bug

Initial Comment:
The documentation for encoding lines at

C:\Python23\Doc\Python-Docs-2.3.1\whatsnew\section-
encodings.html

states:

"Encodings are declared by including a specially 
formatted comment in the first or second line of the 
source file."

In fact, contrary to the implication, the Python 2.3 
parser does not look for lines of the form:

# -*- coding: <encoding> -*-

For example, Python improperly scans the following line 
for an encoding

#@+leo-ver=4-encoding=iso-8859-1.

and reports that iso-8859-1. (note trailing dot) is an 
invalid encoding!

The workaround for my app is to precede this line with 
the following line:

# -*- coding: iso-8859-1 -*-

This makes Python 2.3 happy.

To make myself perfectly clear: Python has absolutely 
no right to complain about comment lines that do not 
have the form:

# -*- coding: <encoding> -*-

Python 2.3.1
Windows XP

Edward K. Ream
edreamleo@charter.net

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

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

From noreply at sourceforge.net  Tue Feb 17 15:46:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 15:48:37 2004
Subject: [ python-Bugs-666219 ] AssertionErrors in httplib
Message-ID: <E1AtC7K-00074D-00@sc8-sf-web4.sourceforge.net>

Bugs item #666219, was opened at 2003-01-11 14:23
Message generated for change (Comment added) made by nicolary
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Skip Montanaro (montanaro)
Assigned to: Jeremy Hylton (jhylton)
Summary: AssertionErrors in httplib

Initial Comment:
I've recently noticed AssertionErrors being raised by
httplib.LineAndFileWrapper.read().  It happens reliably when the server
exits unexpectedly.  Here's an example of an AssertionError in an 
xmlrpclib client when I kill the server it's talking to:

    Traceback (most recent call last):
      File "qa.py", line 22, in ?
        x = s.query(tmpl, st, en, radius, age)
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 985, in __call__
        return self.__send(self.__name, args)
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1269, in __request
        verbose=self.__verbose
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1036, in request
        return self._parse_response(h.getfile(), sock)
      File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1165, in _parse_response
        response = file.read(1024)
      File "/Users/skip/local/lib/python2.3/httplib.py", line 1150, in read
        assert not self._line_consumed and self._line_left
    AssertionError

I don't see a problem with raising an exception in this situation.  I just
wonder if AssertionError is the best exception to raise (unless of course, the cause is a logic error in the httplib code).  If an exception
is being raised because the server went away, I think it would be 
better to raise IncompleteRead.

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

Comment By: Samuel Nicolary (nicolary)
Date: 2004-02-17 20:46

Message:
Logged In: YES 
user_id=27555

I had this problem going against a Novell iChains reverse proxy 
and adding the following to account for an SSLv3 protocol 
bug in the server to the socketmodule.c fixed this problem:

SSL_CTX_set_options(self->ctx, 
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS);

I added this after the SSL_CTX_set_verify call in the 
aforementioned file.  Ther are other bug workaround that one 
can enable or one can enable all of the workarounds with the 
following:

SSL_CTX_set_options(conn->ssl.ctx, SSL_OP_ALL);

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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-29 17:55

Message:
Logged In: YES 
user_id=31392

Thanks for the comment, showme1949.  It's obvious that the
assertion fails in this case.  Fixed by raising an exception
earlier.


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

Comment By: AC (showme1949)
Date: 2003-06-28 09:30

Message:
Logged In: YES 
user_id=811410


OK, I saw this problem pretty in several programs (mine or
others). So I deed some search, here is a log that shown
self._line_consumed, self._line_left, self._line and
self._line_offset with bittorrent.

It is pretty obvious when the assert happens, we have a empty
self._line before we even start to read. Maybe because the
other end closed on us without sending any data.

A suggusted fix is to append 'and len(self._line) != 0'  to
the end of assert.
-------------- My log on the assert -------
==== line_consumeed, line_left ===
0
0

0
=== self._line, line_offset ===
Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python2.2/threading.py", line 414, in
__bootstrap
    self.run()
  File "/usr/lib/python2.2/threading.py", line 402, in run
    apply(self.__target, self.__args, self.__kwargs)
  File
"/usr/lib/python2.2/site-packages/BitTorrent/Rerequester.py",
line 76, in rer
equest
    r = h.read()
  File "/usr/lib/python2.2/httplib.py", line 1148, in read
    assert not self._line_consumed and self._line_left
AssertionError


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

Comment By: Skip Montanaro (montanaro)
Date: 2003-05-05 16:48

Message:
Logged In: YES 
user_id=44345

[small timeout?]

Not since the changes to the makefile() changes to socket.py (or at least
not always).  If the timeout is shorter than the response time you now can
get a socket.error:

>>> socket.setdefaulttimeout(0.05)
>>> manatee = xmlrpclib.ServerProxy("http://manatee.mojam.com:5007")
>>> manatee.noop()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1021, in __call__
    return self.__send(self.__name, args)
  File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1308, in __request
    verbose=self.__verbose
  File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1056, in request
    errcode, errmsg, headers = h.getreply()
  File "/Users/skip/local/lib/python2.3/httplib.py", line 1019, in getreply
    response = self._conn.getresponse()
  File "/Users/skip/local/lib/python2.3/httplib.py", line 770, in getresponse
    response.begin()
  File "/Users/skip/local/lib/python2.3/httplib.py", line 268, in begin
    version, status, reason = self._read_status()
  File "/Users/skip/local/lib/python2.3/httplib.py", line 230, in _read_status
    line = self.fp.readline()
  File "/Users/skip/local/lib/python2.3/socket.py", line 321, in readline
    data = recv(1)
socket.error: (35, 'Resource temporarily unavailable')

I think you may still get the assertion error if the timeout is sufficient to
allow some of the response to be read, but not all of it (though that's just
a guess).

I suspect we're better off just closing this with either "postponed" or
"won't fix" at this point.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-05-05 16:33

Message:
Logged In: YES 
user_id=31392

We can provoke this error by setting a very small timeout,
right?


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

Comment By: Skip Montanaro (montanaro)
Date: 2003-03-20 18:43

Message:
Logged In: YES 
user_id=44345

Sorry for the delay on this.  I think I'm closing in on the
problem.  I've been using Tim O'Malley's timeoutsocket
module for quite awhile.  I noticed the same problem today
when using the new timeout feature in the socket module.
Libraries like xmlrpclib use makefile() to get a file object
to play with.  File objects don't play well with timeouts
because the socket is in non-blocking mode.  I think what
happens here is that the first line of HTTPResponse.
_read_status sets line to the empty string because of the
timeout setting.  Tracing through the code which follows
makes it clear that control will wind up in the HTTP/0.9
chunk of code.

Maybe it's worth adding a test for line == "" after the
readline() call:

        line = self.fp.readline()
        if self.debuglevel > 0:
            print "reply:", repr(line)
        if line == "":
            raise BadStatusLine(line)

That would distinguish an error reading from an 0.9 server
(which would return something with that first readline()
call).

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

Comment By: Skip Montanaro (montanaro)
Date: 2003-01-31 14:13

Message:
Logged In: YES 
user_id=44345

No, sorry, I haven't looked more deeply into the problem.  I did investigate
far enough to also see that the code was in the HTTP/0.9 weeds and am
befuddled about why it would be there.  It's using the vanilla xmlrpclib
module at both ends.  I'll try to spend a little time today.

S

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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-31 14:07

Message:
Logged In: YES 
user_id=31392

Any more info Skip?


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-14 21:18

Message:
Logged In: YES 
user_id=31392

It's definitely the case that an AssertionError shouldn't be
raised.  It was my intention that the assert never fail.  Do
you know which part of the assert fails?  Perhaps you could
change the assert to print the values of _line_consumed and
_line_left and run some more tests.
I can't figure out how this goes wrong.

Also, do you know when the server is sending an HTTP/0.9
response?  I wonder if there's a bug somewhere else and the
client is guessing the wrong protocol version for the response.


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

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

From noreply at sourceforge.net  Tue Feb 17 16:14:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 16:15:34 2004
Subject: [ python-Bugs-898757 ] Python 2.3 encoding parsing bug
Message-ID: <E1AtCXe-0000CA-00@sc8-sf-web4.sourceforge.net>

Bugs item #898757, was opened at 2004-02-17 15:36
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898757&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward K. Ream (edream)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3 encoding parsing bug

Initial Comment:
The documentation for encoding lines at

C:\Python23\Doc\Python-Docs-2.3.1\whatsnew\section-
encodings.html

states:

"Encodings are declared by including a specially 
formatted comment in the first or second line of the 
source file."

In fact, contrary to the implication, the Python 2.3 
parser does not look for lines of the form:

# -*- coding: <encoding> -*-

For example, Python improperly scans the following line 
for an encoding

#@+leo-ver=4-encoding=iso-8859-1.

and reports that iso-8859-1. (note trailing dot) is an 
invalid encoding!

The workaround for my app is to precede this line with 
the following line:

# -*- coding: iso-8859-1 -*-

This makes Python 2.3 happy.

To make myself perfectly clear: Python has absolutely 
no right to complain about comment lines that do not 
have the form:

# -*- coding: <encoding> -*-

Python 2.3.1
Windows XP

Edward K. Ream
edreamleo@charter.net

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-17 22:14

Message:
Logged In: YES 
user_id=38388

Python is behaving correctly and according to the PEP.

The encoding declaration parser will look for "coding[:=][
\t]*<encoding>"
to make it play nice with various different editor encoding
comments
in use today. The format you are quoting is Emacs-style, but
there are also vi-style and various other formats. Most of them
use the "coding[:=]" declaration which is why this parsing
method
was chosen.

Does leo need the trailing dot in the comment ?

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

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

From noreply at sourceforge.net  Tue Feb 17 16:24:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 16:26:00 2004
Subject: [ python-Bugs-791542 ] test_threading
Message-ID: <E1AtChq-000065-00@sc8-sf-web3.sourceforge.net>

Bugs item #791542, was opened at 2003-08-19 14:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791542&group_id=5470

Category: Build
Group: Python 2.2.3
>Status: Open
>Resolution: None
Priority: 5
Submitted By: Shawn Leard (sleard1)
Assigned to: Brett Cannon (bcannon)
Summary: test_threading

Initial Comment:

Due the problems reported with version 2.3 I thought I
would give version 2.2.3 a shot. The problem I am
having here is no matter what switches I pass configure
to disable threading it still tries to test them and as
a result the make test fails.

168 tests OK.
1 test failed:
    test_threading
24 tests skipped:
    test_al test_asynchat test_bsddb test_cd test_cl
test_curses
    test_dl test_email_codecs test_fork1 test_gl
test_imgfile
    test_linuxaudiodev test_minidom test_openpty
test_pyexpat
    test_queue test_sax test_socket_ssl
test_socketserver test_thread
    test_threaded_import test_threadedtempfile test_winreg
    test_winsound

--------

./configure --prefix=/usr/local --with-gnu-ld
--with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld
--enable-nls   --with-included-gettext --with-fpectl
--with-threads=no --without-threads --disable-threads
--with-gnu-as

--------

mars$ /files/local/src/Python-2.2.3/python
test_threading.py
Traceback (most recent call last):
  File "test_threading.py", line 7, in ?
    import threading
  File
"/files/local/src/Python-2.2.3/Lib/threading.py", line
5, in ?
    import thread
ImportError: No module named thread


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 13:24

Message:
Logged In: YES 
user_id=357491

That's fine, Shawn, but I still feel the need to look into it.  There is no 
reason for that to be happening.  I feel I should at least verify that this 
doesn't happen on my box because if it does there is a bug somewhere.

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

Comment By: Shawn Leard (sleard1)
Date: 2004-02-17 05:51

Message:
Logged In: YES 
user_id=328879



Brett,

I am going to close this because the box I had was
redeployed and I have no longer had this problem.

Best Regards,

Shawn


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

Comment By: Shawn Leard (sleard1)
Date: 2003-09-08 13:00

Message:
Logged In: YES 
user_id=328879



I will give this a shot and get back to you.



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

Comment By: Brett Cannon (bcannon)
Date: 2003-09-04 18:53

Message:
Logged In: YES 
user_id=357491

In order to better debug this, can you state what the line says 
when test_threading fails; e.g., "test_sunaudiodev skipped -- ..."?

The test will be run regardless of whether you compiled with 
threads or not, but it should be listed as a skip instead of a 
failure.

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

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

From noreply at sourceforge.net  Tue Feb 17 16:39:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 16:40:34 2004
Subject: [ python-Bugs-897817 ] test_strptime failures on FC2-test
Message-ID: <E1AtCvn-0007Im-00@sc8-sf-web1.sourceforge.net>

Bugs item #897817, was opened at 2004-02-15 21:52
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897817&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Brett Cannon (bcannon)
Summary: test_strptime failures on FC2-test

Initial Comment:
I'm seeing test_strptime failures on this box, running
a version of Fedora Core that's between 1 and the new
test release.

test test_strptime failed -- Traceback (most recent
call last): 
File "Lib/test/test_strptime.py", line 258, in
test_timezone
    self.failUnlessEqual(strp_output.tm_isdst, 0)
AssertionError: -1 != 0

Note that the following line (which tests GMT) also
fails with a -1.

The underlying failure:
>>> import _strptime
>>> strp_output = _strptime.strptime("UTC", "%Z")
>>> strp_output.tm_isdst
-1
>>> strp_output = _strptime.strptime("GMT", "%Z")
>>> strp_output.tm_isdst
-1


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 13:39

Message:
Logged In: YES 
user_id=357491

Anthony, can you let me know what the following commands spit out?::

import time; import _strptime
time.tzname
time.daylight
_strptime.LocaleTime().timezone
_strptime.TimeRE()['Z']

That should be enough info for me to debug this.

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

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

From noreply at sourceforge.net  Tue Feb 17 16:47:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 16:48:21 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1AtD3V-0008EY-00@sc8-sf-web2.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 21:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Arman Bostani (arman0)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float('nan') evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

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

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

From noreply at sourceforge.net  Tue Feb 17 16:50:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 16:52:10 2004
Subject: [ python-Bugs-898253 ] strftime ignores date format on winxp
Message-ID: <E1AtD7A-0008SL-00@sc8-sf-web2.sourceforge.net>

Bugs item #898253, was opened at 2004-02-16 12:19
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898253&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Sherborne (matiu)
>Assigned to: Nobody/Anonymous (nobody)
Summary: strftime ignores date format on winxp

Initial Comment:
On Windows XP in the control panel set your country to
"New Zealand".

This gives a short date format of 'dd-mm-yy'

Now in python:
>>> from time import *
>>> print strftime('%c', localtime)
02/17/04 09:15:10
>>> print strftime('%x', localtime())
02/17/04

This is giving the date in the format 'mm-dd-yy'
(American).

Could it be to do with the 'locale.nl_langinfo' bieng
unavailable in xp?

Versions:
ActivePython 2.3.2 Build 232 (ActiveState Corp.) based
on Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC
v.1200 32 bit (Intel)] on win32
Windows XP Home Edition (up to dateish)

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

>Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 13:50

Message:
Logged In: YES 
user_id=357491

This is a Windows C library bug and nothing to do with our end.  
Since time.strftime is just a wrapper around ISO C's strftime function we 
just pass in the arguments and then pass them back out without fiddling 
with anything.

So unless there is some compiler setting that needs to be set to be more 
locale-sensitive (doubt it, but since I don't have a Windows box I have no 
way of knowing; this is why I am unassigning this from myself) this is 
probably invalid and Microsoft's fault.

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 12:29

Message:
Logged In: YES 
user_id=304464

Sorry, code should be:

>>> from time import *
>>> print strftime('%c', localtime())
02/17/04 09:15:10
>>> print strftime('%x', localtime())
02/17/04

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

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

From noreply at sourceforge.net  Tue Feb 17 16:59:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 17:00:57 2004
Subject: [ python-Bugs-897625 ] time.strftime crashes python
Message-ID: <E1AtDF8-0002rb-00@sc8-sf-web4.sourceforge.net>

Bugs item #897625, was opened at 2004-02-15 13:33
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897625&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Tom Lynn (tlynn)
Assigned to: Brett Cannon (bcannon)
Summary: time.strftime crashes python

Initial Comment:
On Win2k:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Python dumps core.  Is that (ever) expected behaviour?

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

>Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 13:59

Message:
Logged In: YES 
user_id=357491

Should be able to deal with this cleanly by modifying gettmarg() to do 
some sanity checks on the values before returning and letting 
time_strftime() at the struct tm that gettmarg() created.

First have to check the ISO C standard, though, to make sure I don't 
overstep my bounds on the sanity checks (or I could just follow our own 
specs, but that would be too easy  =).

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 12:36

Message:
Logged In: YES 
user_id=304464

On WinXP Home does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\xfcI\xc1w\xf8I\xc1w\xf4I\xc1w\xf0I\xc1w\xecI\xc1w\xe8I\xc1w\xe4I\xc1w\xdcI\xc1w\xd4I\xc1w\xccI\xc1w\xc0I\xc1w\xb4I\xc1w\xacI\xc1w\xa0I\xc1w\x9cI\xc1w\x98I\xc1w\x94I\xc1w\x90I\xc1w\x8cI\xc1w\x88I\xc1w\x84I\xc1w\x80I\xc1w|I\xc1wxI\xc1wtI\xc1wpI\xc1whI\xc1w\I\xc1wTI\xc1wLI\xc1w\x8cI\xc1wDI\xc1w<I\xc1w4I\xc1w(I\xc1wI\xc1w\x14I\xc1w\x08I\xc1w\x04I\xc1w'

ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit
(Intel)] on win32


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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 12:34

Message:
Logged In: YES 
user_id=304464

On my linux system does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\x0e'

Python 2.3.3c1 (#2, Dec  6 2003, 16:44:56)
[GCC 3.3.3 20031203 (prerelease) (Debian)] on linux2

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 12:32

Message:
Logged In: YES 
user_id=304464

Also, please have a look at:
https://sourceforge.net/tracker/index.php?func=detail&aid=898253&group_id=5470&atid=105470

at the same time.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-15 17:23

Message:
Logged In: YES 
user_id=31435

I assume this is specific to Python on Windows using 
Microsoft's C, since this workalike plain C program also dies 
with a memory error while in the bowels of MS's strftime():

#include <stdio.h>
#include <time.h>

void main() {
    struct tm t;
    char buf[256];
    size_t i;

    t.tm_year = 1900 - 1900;
    t.tm_mon = 1 - 1;
    t.tm_mday = 1;
    t.tm_hour = 13;
    t.tm_min = 0;
    t.tm_sec = 0;
    t.tm_wday = -3;
    t.tm_yday = 0;
    t.tm_isdst = -1;

    printf("calling strftime\n");
    i = strftime(buf, sizeof(buf), "%a", &t);
    printf("i: %d\n", i);
}

The problem is the negative value for tm_wday.  MS strftime 
isn't defensive, and uses the negative tm_wday to index into 
nonsense memory.  Ironically, if C had defined the % operator 
in the sane way (meaning Python's way <wink>), a negative 
tm_wday wouldn't have survived for the C library function to 
see.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-15 15:41

Message:
Logged In: YES 
user_id=80475

It is expected.  Well, now that I've confirmed it on Py2.3.3
and Py2.4, yes ;-) 

Is it desirable?  Heck no.

Brett, can you take a look at this?

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

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

From noreply at sourceforge.net  Tue Feb 17 16:47:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 17:03:21 2004
Subject: [ python-Bugs-898757 ] Python 2.3 encoding parsing bug
Message-ID: <E1AtD3Z-0008FF-00@sc8-sf-web2.sourceforge.net>

Bugs item #898757, was opened at 2004-02-17 15:36
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898757&group_id=5470

Category: Parser/Compiler
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Edward K. Ream (edream)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3 encoding parsing bug

Initial Comment:
The documentation for encoding lines at

C:\Python23\Doc\Python-Docs-2.3.1\whatsnew\section-
encodings.html

states:

"Encodings are declared by including a specially 
formatted comment in the first or second line of the 
source file."

In fact, contrary to the implication, the Python 2.3 
parser does not look for lines of the form:

# -*- coding: <encoding> -*-

For example, Python improperly scans the following line 
for an encoding

#@+leo-ver=4-encoding=iso-8859-1.

and reports that iso-8859-1. (note trailing dot) is an 
invalid encoding!

The workaround for my app is to precede this line with 
the following line:

# -*- coding: iso-8859-1 -*-

This makes Python 2.3 happy.

To make myself perfectly clear: Python has absolutely 
no right to complain about comment lines that do not 
have the form:

# -*- coding: <encoding> -*-

Python 2.3.1
Windows XP

Edward K. Ream
edreamleo@charter.net

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

>Comment By: Martin v. L?wis (loewis)
Date: 2004-02-17 22:47

Message:
Logged In: YES 
user_id=21627

Actually, what Python should (and does) really do is to
follow the language specification (the PEP becomes
irrelevant once implemented):

http://www.python.org/doc/current/ref/encodings.html

This gives the precise regexp that is used.

Differences between the language spec and the implementation
would be considered as a bug. Closing this report as not-a-bug.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-17 22:14

Message:
Logged In: YES 
user_id=38388

Python is behaving correctly and according to the PEP.

The encoding declaration parser will look for "coding[:=][
\t]*<encoding>"
to make it play nice with various different editor encoding
comments
in use today. The format you are quoting is Emacs-style, but
there are also vi-style and various other formats. Most of them
use the "coding[:=]" declaration which is why this parsing
method
was chosen.

Does leo need the trailing dot in the comment ?

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

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

From noreply at sourceforge.net  Tue Feb 17 17:59:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 18:00:51 2004
Subject: [ python-Bugs-898757 ] Python 2.3 encoding parsing bug
Message-ID: <E1AtEBf-0003ix-00@sc8-sf-web2.sourceforge.net>

Bugs item #898757, was opened at 2004-02-17 14:36
Message generated for change (Comment added) made by edream
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898757&group_id=5470

Category: Parser/Compiler
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Edward K. Ream (edream)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3 encoding parsing bug

Initial Comment:
The documentation for encoding lines at

C:\Python23\Doc\Python-Docs-2.3.1\whatsnew\section-
encodings.html

states:

"Encodings are declared by including a specially 
formatted comment in the first or second line of the 
source file."

In fact, contrary to the implication, the Python 2.3 
parser does not look for lines of the form:

# -*- coding: <encoding> -*-

For example, Python improperly scans the following line 
for an encoding

#@+leo-ver=4-encoding=iso-8859-1.

and reports that iso-8859-1. (note trailing dot) is an 
invalid encoding!

The workaround for my app is to precede this line with 
the following line:

# -*- coding: iso-8859-1 -*-

This makes Python 2.3 happy.

To make myself perfectly clear: Python has absolutely 
no right to complain about comment lines that do not 
have the form:

# -*- coding: <encoding> -*-

Python 2.3.1
Windows XP

Edward K. Ream
edreamleo@charter.net

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

>Comment By: Edward K. Ream (edream)
Date: 2004-02-17 22:59

Message:
Logged In: YES 
user_id=14056

> Does leo need the trailing dot in the comment?

In general, Leo needs to know where the encoding 
specification ends and a possible end-block-comment delim 
begin.  In specific languages, and in particular Python, Leo 
would not have needed the trailing dot.  Alas, this is a moot 
point.  The only options available to Leo now are:

1. Have the user insert encoding comments by hand or
2. Change the format of files created by Leo.

In other words, no previous 4.x version of Leo (including 4.1 
final, due tomorrow) can ever work with Python 2.3 without 
the user inserting a workaround.

I am most upset that the Pep said one thing in English and 
something almost completely different in the re.  Furthermore, 
what the re implies is a very bad idea: having a _restricted_ 
kind of special-purpose comment is one thing:  having a way-
too-general kind of special-purpose comment is wrong, wrong, 
wrong.  It needlessly invalidates comments that _should_ 
have been none of Python's business.  Yes, I know there was 
a reason for this bad idea; there always is.

Edward

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

Comment By: Martin v. L?wis (loewis)
Date: 2004-02-17 21:47

Message:
Logged In: YES 
user_id=21627

Actually, what Python should (and does) really do is to
follow the language specification (the PEP becomes
irrelevant once implemented):

http://www.python.org/doc/current/ref/encodings.html

This gives the precise regexp that is used.

Differences between the language spec and the implementation
would be considered as a bug. Closing this report as not-a-bug.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-17 21:14

Message:
Logged In: YES 
user_id=38388

Python is behaving correctly and according to the PEP.

The encoding declaration parser will look for "coding[:=][
\t]*<encoding>"
to make it play nice with various different editor encoding
comments
in use today. The format you are quoting is Emacs-style, but
there are also vi-style and various other formats. Most of them
use the "coding[:=]" declaration which is why this parsing
method
was chosen.

Does leo need the trailing dot in the comment ?

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

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

From noreply at sourceforge.net  Tue Feb 17 18:06:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 17 18:08:13 2004
Subject: [ python-Bugs-831271 ] httplib.HTTPConnection._send_request header
	parsing bug
Message-ID: <E1AtEIo-0005ej-00@sc8-sf-web3.sourceforge.net>

Bugs item #831271, was opened at 2003-10-27 21:57
Message generated for change (Comment added) made by kajtzu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831271&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Jason R. Coombs (jaraco)
Assigned to: Alex Martelli (aleax)
Summary: httplib.HTTPConnection._send_request header parsing bug

Initial Comment:
The test on lines 730-731 of httplib.py as released with 
Python 2.3.2 doesn't do what it's intended to do.

Consider
>>> headers = { 'hoST': 'www.someplace.org' }
>>> 'Host' in ( headers or [k for k in headers.iterkeys() if 
k.lower() == 'host' ] )
False

This sample code demonstrates that the code in httplib 
at line 730 doesn't work as intended (it should return 
true for any dict who's keys include 'host' of any case).

Clearly the 'or' syntax has confused someone here, 
because the portion after the or (if executed) is always 
an empty list.  I recommend instead

        if 'host' in map( str.lower, headers.keys() ):

Or a better general solution might be to force all header 
keys to be case-insensitive strings by overriding str and 
dict to new case-insensitive versions, something like the 
attached.  This idea, however, is just a suggestion, and 
probably needs to be thought through more thoroughly.

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

Comment By: Kaj J. Niemi (kajtzu)
Date: 2004-02-18 01:06

Message:
Logged In: YES 
user_id=978076

Won't this fail if Host is None? Reason I'm asking is that
this changed between python 2.3.2 and 2.3.3 and broke
something :)

  File "/usr/lib/python2.3/httplib.py", line 718, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python2.3/httplib.py", line 730, in
_send_request
    if 'host' in [k.lower() for k in headers]:
AttributeError: 'NoneType' object has no attribute 'lower'

<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112590>

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

Comment By: Alex Martelli (aleax)
Date: 2003-11-02 18:51

Message:
Logged In: YES 
user_id=60314

You're certainly right that lines 730-731 cannot be correct, for exactly the reason you specify; and that forcing case-insensitive header dicts may be a cool idea but it's too invasive for such a simple fix.  I've done some timing and I think the simplest and fastest way to check is:
if 'host' in [k.lower() for k in headers]:
accordingly, I have committed this change to the 2.3 branch in CVS.

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

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

From noreply at sourceforge.net  Wed Feb 18 03:37:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 18 03:38:32 2004
Subject: [ python-Bugs-899423 ] Duplicated <link rel="next"> in <head>
Message-ID: <E1AtNCh-0008Fa-00@sc8-sf-web1.sourceforge.net>

Bugs item #899423, was opened at 2004-02-18 08:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899423&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Joseph Walton (josephw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Duplicated <link rel="next"> in <head>

Initial Comment:
Many of the documentation's navigation links include
'rel="next"' twice. This confuses the Mozilla link
toolbar, resulting in a popup 'next' button with the
same document offered twice.

e.g., tut/node1.html:

...
<LINK REL="next" HREF="node2.html">
<LINK REL="prev" HREF="tut.html">
<LINK REL="parent" HREF="tut.html">
<LINK REL="next" HREF="node2.html">
...


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

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

From noreply at sourceforge.net  Wed Feb 18 03:39:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 18 03:41:19 2004
Subject: [ python-Bugs-899423 ] Duplicated <link rel=
Message-ID: <E1AtNFN-0008P0-00@sc8-sf-web1.sourceforge.net>

Bugs item #899423, was opened at 2004-02-18 08:37
Message generated for change (Settings changed) made by josephw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899423&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 2
Submitted By: Joseph Walton (josephw)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Duplicated <link rel=

Initial Comment:
Many of the documentation's navigation links include
'rel="next"' twice. This confuses the Mozilla link
toolbar, resulting in a popup 'next' button with the
same document offered twice.

e.g., tut/node1.html:

...
<LINK REL="next" HREF="node2.html">
<LINK REL="prev" HREF="tut.html">
<LINK REL="parent" HREF="tut.html">
<LINK REL="next" HREF="node2.html">
...


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

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

From noreply at sourceforge.net  Wed Feb 18 12:41:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 18 12:42:35 2004
Subject: [ python-Bugs-781614 ] Windows _bsddb link warnings
Message-ID: <E1AtVh3-0006ZE-00@sc8-sf-web2.sourceforge.net>

Bugs item #781614, was opened at 2003-08-01 19:04
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Dunn (robind)
Assigned to: Thomas Heller (theller)
Summary: Windows _bsddb link warnings

Initial Comment:
Hi,

The PCbuild/readme.txt says this:

'''
    XXX We're actually linking against
Release_static\libdb41s.lib.
    XXX This yields the following warnings:
"""
Compiling...
_bsddb.c
Linking...
   Creating library ./_bsddb.lib and object ./_bsddb.exp
LINK : warning LNK4049: locally defined symbol
"_malloc" imported
LINK : warning LNK4049: locally defined symbol "_free"
imported
LINK : warning LNK4049: locally defined symbol
"_fclose" imported
LINK : warning LNK4049: locally defined symbol "_fopen"
imported
_bsddb.pyd - 0 error(s), 4 warning(s)
"""
    XXX This isn't encouraging, but I don't know what
to do about it.
'''

The cause of this is the fact that libdb41s.lib is
built with the flags for using the "Multithreaded" C
RTL but Python uses the "MUltithreaded DLL" C RTL.  In
other words, libdb is specifying that the C RTL should
be linked statically but Python wants to link to it
statically. 

To avoid these warnings the instructions can be changed
to specify that the builder should change the flags in
the Berkeley_DB project.  Also you should probably link
with the Debug_static\libdb41sd.lib when building the
debug version of Python.


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

>Comment By: Thomas Heller (theller)
Date: 2004-02-18 18:41

Message:
Logged In: YES 
user_id=11105

It looks to me like we could link to the import library
build_win32\Release\libdb41.lib instead of  the static
library build_win32\Release_static\libdb41s.lib.

The former is built with 'multithreaded dll' flags.  The
downside is that libdb41.dll plus MSVCP60.DLL would have to
be distributed.

Are the linker warnings a real problem, or only cosmetical?

Of course we have to update the build procedure for 2.4
anyway...

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-17 00:54

Message:
Logged In: YES 
user_id=31435

Thomas, you have any insight into this one?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-08-01 21:50

Message:
Logged In: YES 
user_id=21627

Can you propose a specific patch?

Also, it would be preferable if changing the source code of
the Sleepycat distribution would not be necessary.

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

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

From noreply at sourceforge.net  Wed Feb 18 12:46:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 18 13:53:58 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1AtVmL-0006x2-00@sc8-sf-web3.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 21:47
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Arman Bostani (arman0)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float('nan') evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

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

>Comment By: Michael Hudson (mwh)
Date: 2004-02-18 17:46

Message:
Logged In: YES 
user_id=6656

Man, that's strange (I see the same behaviour on my redhat 9
box with 2.3.3).

I don't have time to dig right now, but if you want to,
playing with equivalent C programs would be a very good start.

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

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

From noreply at sourceforge.net  Wed Feb 18 14:58:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 18 14:59:33 2004
Subject: [ python-Bugs-781614 ] Windows _bsddb link warnings
Message-ID: <E1AtXpa-0001YB-00@sc8-sf-web4.sourceforge.net>

Bugs item #781614, was opened at 2003-08-01 19:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Dunn (robind)
Assigned to: Thomas Heller (theller)
Summary: Windows _bsddb link warnings

Initial Comment:
Hi,

The PCbuild/readme.txt says this:

'''
    XXX We're actually linking against
Release_static\libdb41s.lib.
    XXX This yields the following warnings:
"""
Compiling...
_bsddb.c
Linking...
   Creating library ./_bsddb.lib and object ./_bsddb.exp
LINK : warning LNK4049: locally defined symbol
"_malloc" imported
LINK : warning LNK4049: locally defined symbol "_free"
imported
LINK : warning LNK4049: locally defined symbol
"_fclose" imported
LINK : warning LNK4049: locally defined symbol "_fopen"
imported
_bsddb.pyd - 0 error(s), 4 warning(s)
"""
    XXX This isn't encouraging, but I don't know what
to do about it.
'''

The cause of this is the fact that libdb41s.lib is
built with the flags for using the "Multithreaded" C
RTL but Python uses the "MUltithreaded DLL" C RTL.  In
other words, libdb is specifying that the C RTL should
be linked statically but Python wants to link to it
statically. 

To avoid these warnings the instructions can be changed
to specify that the builder should change the flags in
the Berkeley_DB project.  Also you should probably link
with the Debug_static\libdb41sd.lib when building the
debug version of Python.


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

>Comment By: Martin v. L?wis (loewis)
Date: 2004-02-18 20:58

Message:
Logged In: YES 
user_id=21627

I think we should avoid linking with the DLL if possible; in
some application context, it may be impossible to find the
DLL dynamically, or there might be confusion which DLL to load.

The linker warning means that there is a conflict between
the static (libc.a) and dynamic (msvcr71.dll) version of
_free, etc, which potentially means that we are linking
conflicting copies of the CRT, which is potentially dangerous.

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

Comment By: Thomas Heller (theller)
Date: 2004-02-18 18:41

Message:
Logged In: YES 
user_id=11105

It looks to me like we could link to the import library
build_win32\Release\libdb41.lib instead of  the static
library build_win32\Release_static\libdb41s.lib.

The former is built with 'multithreaded dll' flags.  The
downside is that libdb41.dll plus MSVCP60.DLL would have to
be distributed.

Are the linker warnings a real problem, or only cosmetical?

Of course we have to update the build procedure for 2.4
anyway...

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-17 00:54

Message:
Logged In: YES 
user_id=31435

Thomas, you have any insight into this one?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-08-01 21:50

Message:
Logged In: YES 
user_id=21627

Can you propose a specific patch?

Also, it would be preferable if changing the source code of
the Sleepycat distribution would not be necessary.

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

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

From noreply at sourceforge.net  Wed Feb 18 15:18:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 18 15:19:46 2004
Subject: [ python-Bugs-781614 ] Windows _bsddb link warnings
Message-ID: <E1AtY9F-0008UQ-00@sc8-sf-web1.sourceforge.net>

Bugs item #781614, was opened at 2003-08-01 19:04
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Dunn (robind)
Assigned to: Thomas Heller (theller)
Summary: Windows _bsddb link warnings

Initial Comment:
Hi,

The PCbuild/readme.txt says this:

'''
    XXX We're actually linking against
Release_static\libdb41s.lib.
    XXX This yields the following warnings:
"""
Compiling...
_bsddb.c
Linking...
   Creating library ./_bsddb.lib and object ./_bsddb.exp
LINK : warning LNK4049: locally defined symbol
"_malloc" imported
LINK : warning LNK4049: locally defined symbol "_free"
imported
LINK : warning LNK4049: locally defined symbol
"_fclose" imported
LINK : warning LNK4049: locally defined symbol "_fopen"
imported
_bsddb.pyd - 0 error(s), 4 warning(s)
"""
    XXX This isn't encouraging, but I don't know what
to do about it.
'''

The cause of this is the fact that libdb41s.lib is
built with the flags for using the "Multithreaded" C
RTL but Python uses the "MUltithreaded DLL" C RTL.  In
other words, libdb is specifying that the C RTL should
be linked statically but Python wants to link to it
statically. 

To avoid these warnings the instructions can be changed
to specify that the builder should change the flags in
the Berkeley_DB project.  Also you should probably link
with the Debug_static\libdb41sd.lib when building the
debug version of Python.


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

>Comment By: Thomas Heller (theller)
Date: 2004-02-18 21:18

Message:
Logged In: YES 
user_id=11105

Potentially dangerous - of course.  The question is whether
this is responsible for some bugs or not.

If we cannot link to the DLL then we have to change the
build settings for the static builds of libdb41s.lib.

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

Comment By: Martin v. L?wis (loewis)
Date: 2004-02-18 20:58

Message:
Logged In: YES 
user_id=21627

I think we should avoid linking with the DLL if possible; in
some application context, it may be impossible to find the
DLL dynamically, or there might be confusion which DLL to load.

The linker warning means that there is a conflict between
the static (libc.a) and dynamic (msvcr71.dll) version of
_free, etc, which potentially means that we are linking
conflicting copies of the CRT, which is potentially dangerous.

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

Comment By: Thomas Heller (theller)
Date: 2004-02-18 18:41

Message:
Logged In: YES 
user_id=11105

It looks to me like we could link to the import library
build_win32\Release\libdb41.lib instead of  the static
library build_win32\Release_static\libdb41s.lib.

The former is built with 'multithreaded dll' flags.  The
downside is that libdb41.dll plus MSVCP60.DLL would have to
be distributed.

Are the linker warnings a real problem, or only cosmetical?

Of course we have to update the build procedure for 2.4
anyway...

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-17 00:54

Message:
Logged In: YES 
user_id=31435

Thomas, you have any insight into this one?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-08-01 21:50

Message:
Logged In: YES 
user_id=21627

Can you propose a specific patch?

Also, it would be preferable if changing the source code of
the Sleepycat distribution would not be necessary.

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

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

From noreply at sourceforge.net  Wed Feb 18 19:48:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 18 19:50:16 2004
Subject: [ python-Bugs-897872 ] Unknown color name on HP-UX
Message-ID: <E1AtcMt-0003tg-00@sc8-sf-web2.sourceforge.net>

Bugs item #897872, was opened at 2004-02-16 03:37
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897872&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unknown color name on HP-UX

Initial Comment:
When I click on a node in the class browser tree widget, 
I get: 

TclError: unknown color name "darkblue".

This is coming from line 253 in TreeWidget.py where the 
background color is hard-coded as "darkblue".

On HP-UX 11.11 there is no entry for "darkblue" in 
rgb.txt.



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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-18 19:48

Message:
Logged In: YES 
user_id=593130

Given the apparent absence of problems on others systems, 
perhaps the absence of a 'darkblue' entry is a bug that should 
be reported to HP.  Do you know anything of the specs for 
rgb.txt?  And can you add such an entry to fix the problem?

If you are sure the absence if legit, what color can be 
depended on if 'darkblue' does not work?

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

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

From noreply at sourceforge.net  Thu Feb 19 01:39:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 01:40:50 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1Athps-0006Tu-00@sc8-sf-web2.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 21:47
Message generated for change (Comment added) made by eggert
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Arman Bostani (arman0)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float('nan') evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 06:39

Message:
Logged In: YES 
user_id=17848

There's an easy fix.  Python has long mishandled IEEE
special values
(see bugs 445484 and 737648, and see PEP 42 "Non-accidental
IEEE-754
support" as well as PEP 754), and solving the problem in
general will
be some work.  However, solving the NaN-comparison problem
is easy:
simply sort NaNs consistently before all numbers.  This is
the same
algorithm that GNU "sort -g" has used for quite some time.

===================================================================
RCS file: Include/pyport.h,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Include/pyport.h
--- Include/pyport.h	2003/09/30 14:56:50	2.3.3.0
+++ Include/pyport.h	2004/02/19 06:06:10
@@ -221,6 +221,13 @@ extern "C" {
 #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
 #endif
 
+/* Py_IS_NAN(X)
+ * Return 1 if float or double arg is not a number (NaN),
else 0.
+ * Caution:
+ *    X is evaluated more than once.
+ */
+#define Py_IS_NAN(X) ((X) != (X))
+
 /* Py_IS_INFINITY(X)
  * Return 1 if float or double arg is an infinity, else 0.
  * Caution:
===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Objects/floatobject.c
--- Objects/floatobject.c	2003/06/28 20:04:24	2.3.3.0
+++ Objects/floatobject.c	2004/02/19 06:03:37
@@ -367,7 +367,21 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	int c;
+	/* Because of NaNs IEEE arithmetic is not a total order.
+	 * Python works better with total orders, so use the same
+	 * total order that GNU sort does: NaNs sort before numbers,
+	 * and NaNs are sorted by internal bit-pattern.
+	 */
+	return ((i < j) ? -1
+		: (i > j) ? 1
+		: (i == j) ? 0
+		: !Py_IS_NAN(j) ? -1 /* i is NaN, j is not */
+		: !Py_IS_NAN(i) ? 1  /* j is NAN, i is not */
+		: /* i and j are both NaNs; compare them bitwise */
+		  ((c = memcmp(&v->ob_fval, &w->ob_fval, sizeof(v->ob_fval)))
+		   < 0) ? -1
+		: (c > 0));
 }
 
 static long


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-18 17:46

Message:
Logged In: YES 
user_id=6656

Man, that's strange (I see the same behaviour on my redhat 9
box with 2.3.3).

I don't have time to dig right now, but if you want to,
playing with equivalent C programs would be a very good start.

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

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

From noreply at sourceforge.net  Thu Feb 19 02:14:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 02:15:41 2004
Subject: [ python-Bugs-900071 ] optparse: usage issues
Message-ID: <E1AtiO2-0008E6-00@sc8-sf-web3.sourceforge.net>

Bugs item #900071, was opened at 2004-02-19 09:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900071&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Nobody/Anonymous (nobody)
Summary: optparse: usage issues

Initial Comment:
current documentation states that 

usage = "usage: %prog [options] arg1 arg2"
parser = OptionParser(usage=usage)

would yield

usage: <yourscript> [options] arg1 arg2

however, using python 2.3.2

usage = "Usage: %prog [options] file"

yields:

usage: Usage <yourscript> [options] file"


IMO, it should be possible to replace the whole thing
(think i18n)

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

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

From noreply at sourceforge.net  Thu Feb 19 03:05:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 03:07:08 2004
Subject: [ python-Bugs-900092 ] hotshot.stats.load
Message-ID: <E1AtjBm-00020r-00@sc8-sf-web3.sourceforge.net>

Bugs item #900092, was opened at 2004-02-19 10:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Nobody/Anonymous (nobody)
Summary: hotshot.stats.load

Initial Comment:
trying to do a 

hotshot.stats.load("myprofiling_file.prof")

fails with assertionerror

assert not self._stack


python 2.3.2 on WinXP



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

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

From noreply at sourceforge.net  Thu Feb 19 04:09:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 04:11:02 2004
Subject: [ python-Bugs-900112 ] cgi.fieldStorage doesn't grok standards env.
	variables
Message-ID: <E1AtkBR-0004yP-00@sc8-sf-web2.sourceforge.net>

Bugs item #900112, was opened at 2004-02-19 09:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900112&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominique Haza?l-Massieux (nimbustier)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.fieldStorage doesn't grok standards env. variables

Initial Comment:
The cgi.FieldStorage object has a headers property,
defined as:

"headers         : header dictionary-like object; default:
    taken from environ as per CGI spec"

But the CGI Spec gives a list of well-known environment
variables, plus a generic method to read environment
variables (those starting with HTTP_), that are *not*
read and parsred in this dictionary.
http://hoohoo.ncsa.uiuc.edu/cgi/env.html



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

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

From noreply at sourceforge.net  Thu Feb 19 12:34:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 12:35:41 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1Ats3l-0006Ez-00@sc8-sf-web3.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 16:47
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Arman Bostani (arman0)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float('nan') evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-19 12:34

Message:
Logged In: YES 
user_id=31435

Sorry, the patch can't work:  C89 says nothing about what 
happens when NaNs are compared, and it's in fact not the 
case across platforms that "x != x" returns 1 when x is a NaN.

The most important counter-example for Python is that the 
following prints

1.#INF
-1.#IND
1

under MSVC 6.

#include <stdio.h>

void main()
{
    double x = 1e300 * 1e300;
    printf("%g\n", x);
    x -= x;
    printf("%g\n", x);
    printf("%d\n", x == x);
}


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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 01:39

Message:
Logged In: YES 
user_id=17848

There's an easy fix.  Python has long mishandled IEEE
special values
(see bugs 445484 and 737648, and see PEP 42 "Non-accidental
IEEE-754
support" as well as PEP 754), and solving the problem in
general will
be some work.  However, solving the NaN-comparison problem
is easy:
simply sort NaNs consistently before all numbers.  This is
the same
algorithm that GNU "sort -g" has used for quite some time.

===================================================================
RCS file: Include/pyport.h,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Include/pyport.h
--- Include/pyport.h	2003/09/30 14:56:50	2.3.3.0
+++ Include/pyport.h	2004/02/19 06:06:10
@@ -221,6 +221,13 @@ extern "C" {
 #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
 #endif
 
+/* Py_IS_NAN(X)
+ * Return 1 if float or double arg is not a number (NaN),
else 0.
+ * Caution:
+ *    X is evaluated more than once.
+ */
+#define Py_IS_NAN(X) ((X) != (X))
+
 /* Py_IS_INFINITY(X)
  * Return 1 if float or double arg is an infinity, else 0.
  * Caution:
===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Objects/floatobject.c
--- Objects/floatobject.c	2003/06/28 20:04:24	2.3.3.0
+++ Objects/floatobject.c	2004/02/19 06:03:37
@@ -367,7 +367,21 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	int c;
+	/* Because of NaNs IEEE arithmetic is not a total order.
+	 * Python works better with total orders, so use the same
+	 * total order that GNU sort does: NaNs sort before numbers,
+	 * and NaNs are sorted by internal bit-pattern.
+	 */
+	return ((i < j) ? -1
+		: (i > j) ? 1
+		: (i == j) ? 0
+		: !Py_IS_NAN(j) ? -1 /* i is NaN, j is not */
+		: !Py_IS_NAN(i) ? 1  /* j is NAN, i is not */
+		: /* i and j are both NaNs; compare them bitwise */
+		  ((c = memcmp(&v->ob_fval, &w->ob_fval, sizeof(v->ob_fval)))
+		   < 0) ? -1
+		: (c > 0));
 }
 
 static long


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-18 12:46

Message:
Logged In: YES 
user_id=6656

Man, that's strange (I see the same behaviour on my redhat 9
box with 2.3.3).

I don't have time to dig right now, but if you want to,
playing with equivalent C programs would be a very good start.

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

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

From noreply at sourceforge.net  Thu Feb 19 13:23:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 13:24:51 2004
Subject: [ python-Bugs-900494 ] win shell interpreter error (arithmetic)
Message-ID: <E1AtspU-0002FA-00@sc8-sf-web4.sourceforge.net>

Bugs item #900494, was opened at 2004-02-19 12:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900494&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Okamura (hillvillage)
Assigned to: Nobody/Anonymous (nobody)
Summary: win shell interpreter error (arithmetic)

Initial Comment:
In a shell (2.2.2)  running on Win2k, the numeric
answer to ".090 + .15" is incorrect. Instead of .240
the shell returns .2399999999999999...

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

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

From noreply at sourceforge.net  Thu Feb 19 13:30:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 13:31:58 2004
Subject: [ python-Feature Requests-900502 ] bundlebuilder: some way to add
	non-py files in packages
Message-ID: <E1AtswN-00036X-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #900502, was opened at 2004-02-19 10:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900502&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bundlebuilder: some way to add non-py files in packages

Initial Comment:
I would like some way to load non-python code that is 
contained in packages. In other words, suppose I have:
maindir/
  helpdir/
    __init__.py
    index.html
    ...other python code and help files

I'd like some way to specify that the code in helpdir be 
loaded as code (compiled and the source discarded) but that 
the other files also be copied over. Presently includePackages 
only copies over python files.

The best workaround I've found so far is to specify the 
package in two separate arguments to buildapp: 
includePackages and resources. That copies everything 
(including the python source) and also compiles everything, 
so one ends up with both .py and .pyc files. I then look in 
that folder and discard the python source after 
bundlebuilder is finished. (I suppose that step is optional.)

Simply modifying includePackages so it included non-python 
files is my first thought. It might occasionally include stuff 
that wasn't wanted, but aside from on occasional README 
or something, I doubt it would amount to anything 
significant in most cases.

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

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

From noreply at sourceforge.net  Thu Feb 19 13:36:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 13:37:40 2004
Subject: [ python-Feature Requests-900506 ] bundlebuilder: an arg to disable
	zipping the code
Message-ID: <E1Att1u-0003OZ-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #900506, was opened at 2004-02-19 10:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900506&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bundlebuilder: an arg to disable zipping the code

Initial Comment:
I'd like an argument to bundlebuilder.buildapp that disables 
zipping the Python code.

Actually, what I'd really like is some way to specify that 
certain packages should appear unzipped, e.g.:
/Contents/Resources/
  Modules.zip
  special_nonzipped_package/

but I suspect that's too complicated compared to simply not 
zipping anything.

The reason I want this is I have code that does two different 
things that break when zipped:
- Auto-loads modules found by hunting for them in a 
directory tree. (I could probably learn to search within a zip 
file, but yecch).
- Contains resources (sound files and html files) mixed with 
python code. These resources have to be accessed as files.

Right now I'm using:
bundlebuilder.USE_ZIPIMPORT = False

and it works, but simply importing bundlebuilder has it do 
some things it probably shouldn't do if I am not zipping files. 
(In other words I can only set USE_ZIPIMPORT a bit late, 
and I'm not sure all the consequences are harmless.)

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

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

From noreply at sourceforge.net  Thu Feb 19 13:37:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 13:38:44 2004
Subject: [ python-Bugs-900494 ] win shell interpreter error (arithmetic)
Message-ID: <E1Att2q-0001AY-00@sc8-sf-web3.sourceforge.net>

Bugs item #900494, was opened at 2004-02-19 13:23
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900494&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Mark Okamura (hillvillage)
Assigned to: Nobody/Anonymous (nobody)
Summary: win shell interpreter error (arithmetic)

Initial Comment:
In a shell (2.2.2)  running on Win2k, the numeric
answer to ".090 + .15" is incorrect. Instead of .240
the shell returns .2399999999999999...

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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-19 13:37

Message:
Logged In: YES 
user_id=31435

Not a bug; read the tutorial appendix:

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



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

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

From noreply at sourceforge.net  Thu Feb 19 13:37:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 13:39:11 2004
Subject: [ python-Bugs-900494 ] win shell interpreter error (arithmetic)
Message-ID: <E1Att3J-0001WZ-00@sc8-sf-web2.sourceforge.net>

Bugs item #900494, was opened at 2004-02-19 19:23
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900494&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Mark Okamura (hillvillage)
Assigned to: Nobody/Anonymous (nobody)
Summary: win shell interpreter error (arithmetic)

Initial Comment:
In a shell (2.2.2)  running on Win2k, the numeric
answer to ".090 + .15" is incorrect. Instead of .240
the shell returns .2399999999999999...

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

>Comment By: Thomas Heller (theller)
Date: 2004-02-19 19:37

Message:
Logged In: YES 
user_id=11105

This is not a bug - see
<http://www.python.org/doc/current/tut/node15.html#SECTION0015100000000000000000>

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 19:37

Message:
Logged In: YES 
user_id=31435

Not a bug; read the tutorial appendix:

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



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

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

From noreply at sourceforge.net  Thu Feb 19 13:44:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 13:45:45 2004
Subject: [ python-Feature Requests-900514 ] bundlebuilder: easily keep main
	routine in orig location
Message-ID: <E1Att9j-0003oD-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #900514, was opened at 2004-02-19 10:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900514&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bundlebuilder: easily keep main routine in orig location

Initial Comment:
I'd like to ask that bundlebuilder.py keep the main routine in 
its original location with respect to whatever package it 
appears in, i.e. if the app's main is
MyPgk/Main.py

then the code is put in MyPkg:
Contents/Resources/Modules.zip
      /MyPkg/Main.py

or if no zipping is done:
Contents/Resources/MyPkg/Main.py

I fear this may be too difficult to be worth the work, but I 
wasn't sure and felt it better to ask.

The issue is (as in my 2 previous bundlebuilder requests) 
making it easier to write cross-platform code. If one carefully 
develops code for Mac then one can easily organize it such 
that it fits perfectly within bundlebuilder's assumptions.

But in my case I wrote code to run under unix first, then 
tried to get a working double-clickable Mac app, and it was a 
a surprising amount of work. Among other things, I had to 
rewrite my Main.py so it could be moved relative to its 
package (not a really big deal, but surprising). The other 
requests would simplify or eliminate cleanup work I do after 
the bundle is built.

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

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

From noreply at sourceforge.net  Thu Feb 19 13:47:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 13:49:05 2004
Subject: [ python-Bugs-900494 ] win shell interpreter error (arithmetic)
Message-ID: <E1AttCr-00024T-00@sc8-sf-web2.sourceforge.net>

Bugs item #900494, was opened at 2004-02-19 12:23
Message generated for change (Comment added) made by hillvillage
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900494&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Mark Okamura (hillvillage)
Assigned to: Nobody/Anonymous (nobody)
Summary: win shell interpreter error (arithmetic)

Initial Comment:
In a shell (2.2.2)  running on Win2k, the numeric
answer to ".090 + .15" is incorrect. Instead of .240
the shell returns .2399999999999999...

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

>Comment By: Mark Okamura (hillvillage)
Date: 2004-02-19 12:47

Message:
Logged In: YES 
user_id=979565

I stand corrected. Should have read the tutorial
(completely). Thanks for the responses.

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

Comment By: Thomas Heller (theller)
Date: 2004-02-19 12:37

Message:
Logged In: YES 
user_id=11105

This is not a bug - see
<http://www.python.org/doc/current/tut/node15.html#SECTION0015100000000000000000>

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 12:37

Message:
Logged In: YES 
user_id=31435

Not a bug; read the tutorial appendix:

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



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

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

From noreply at sourceforge.net  Thu Feb 19 14:01:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 14:02:53 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1AttQC-00052D-00@sc8-sf-web1.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 21:47
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Arman Bostani (arman0)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float('nan') evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

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

>Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:01

Message:
Logged In: YES 
user_id=6656

Consider the attached.  It implements rich comparisons for
floats, which makes the behaviour on linux at least very
much less silly.  All tests except for the
considered-hopeless-on-this box audio tests and the new
test_tcl pass.  Even test_bsddb passed! Twice!  (I'm not
sure I can claim credit for this :-)

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 17:34

Message:
Logged In: YES 
user_id=31435

Sorry, the patch can't work:  C89 says nothing about what 
happens when NaNs are compared, and it's in fact not the 
case across platforms that "x != x" returns 1 when x is a NaN.

The most important counter-example for Python is that the 
following prints

1.#INF
-1.#IND
1

under MSVC 6.

#include <stdio.h>

void main()
{
    double x = 1e300 * 1e300;
    printf("%g\n", x);
    x -= x;
    printf("%g\n", x);
    printf("%d\n", x == x);
}


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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 06:39

Message:
Logged In: YES 
user_id=17848

There's an easy fix.  Python has long mishandled IEEE
special values
(see bugs 445484 and 737648, and see PEP 42 "Non-accidental
IEEE-754
support" as well as PEP 754), and solving the problem in
general will
be some work.  However, solving the NaN-comparison problem
is easy:
simply sort NaNs consistently before all numbers.  This is
the same
algorithm that GNU "sort -g" has used for quite some time.

===================================================================
RCS file: Include/pyport.h,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Include/pyport.h
--- Include/pyport.h	2003/09/30 14:56:50	2.3.3.0
+++ Include/pyport.h	2004/02/19 06:06:10
@@ -221,6 +221,13 @@ extern "C" {
 #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
 #endif
 
+/* Py_IS_NAN(X)
+ * Return 1 if float or double arg is not a number (NaN),
else 0.
+ * Caution:
+ *    X is evaluated more than once.
+ */
+#define Py_IS_NAN(X) ((X) != (X))
+
 /* Py_IS_INFINITY(X)
  * Return 1 if float or double arg is an infinity, else 0.
  * Caution:
===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Objects/floatobject.c
--- Objects/floatobject.c	2003/06/28 20:04:24	2.3.3.0
+++ Objects/floatobject.c	2004/02/19 06:03:37
@@ -367,7 +367,21 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	int c;
+	/* Because of NaNs IEEE arithmetic is not a total order.
+	 * Python works better with total orders, so use the same
+	 * total order that GNU sort does: NaNs sort before numbers,
+	 * and NaNs are sorted by internal bit-pattern.
+	 */
+	return ((i < j) ? -1
+		: (i > j) ? 1
+		: (i == j) ? 0
+		: !Py_IS_NAN(j) ? -1 /* i is NaN, j is not */
+		: !Py_IS_NAN(i) ? 1  /* j is NAN, i is not */
+		: /* i and j are both NaNs; compare them bitwise */
+		  ((c = memcmp(&v->ob_fval, &w->ob_fval, sizeof(v->ob_fval)))
+		   < 0) ? -1
+		: (c > 0));
 }
 
 static long


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-18 17:46

Message:
Logged In: YES 
user_id=6656

Man, that's strange (I see the same behaviour on my redhat 9
box with 2.3.3).

I don't have time to dig right now, but if you want to,
playing with equivalent C programs would be a very good start.

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

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

From noreply at sourceforge.net  Thu Feb 19 14:39:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 14:41:18 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1Atu1P-0007MV-00@sc8-sf-web1.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 21:47
Message generated for change (Settings changed) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Arman Bostani (arman0)
>Assigned to: Michael Hudson (mwh)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float('nan') evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

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

>Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:39

Message:
Logged In: YES 
user_id=6656

Tim said yes.

Objects/floatobject.c revision 2.127
Misc/NEWS revision 1.936

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:01

Message:
Logged In: YES 
user_id=6656

Consider the attached.  It implements rich comparisons for
floats, which makes the behaviour on linux at least very
much less silly.  All tests except for the
considered-hopeless-on-this box audio tests and the new
test_tcl pass.  Even test_bsddb passed! Twice!  (I'm not
sure I can claim credit for this :-)

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 17:34

Message:
Logged In: YES 
user_id=31435

Sorry, the patch can't work:  C89 says nothing about what 
happens when NaNs are compared, and it's in fact not the 
case across platforms that "x != x" returns 1 when x is a NaN.

The most important counter-example for Python is that the 
following prints

1.#INF
-1.#IND
1

under MSVC 6.

#include <stdio.h>

void main()
{
    double x = 1e300 * 1e300;
    printf("%g\n", x);
    x -= x;
    printf("%g\n", x);
    printf("%d\n", x == x);
}


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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 06:39

Message:
Logged In: YES 
user_id=17848

There's an easy fix.  Python has long mishandled IEEE
special values
(see bugs 445484 and 737648, and see PEP 42 "Non-accidental
IEEE-754
support" as well as PEP 754), and solving the problem in
general will
be some work.  However, solving the NaN-comparison problem
is easy:
simply sort NaNs consistently before all numbers.  This is
the same
algorithm that GNU "sort -g" has used for quite some time.

===================================================================
RCS file: Include/pyport.h,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Include/pyport.h
--- Include/pyport.h	2003/09/30 14:56:50	2.3.3.0
+++ Include/pyport.h	2004/02/19 06:06:10
@@ -221,6 +221,13 @@ extern "C" {
 #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
 #endif
 
+/* Py_IS_NAN(X)
+ * Return 1 if float or double arg is not a number (NaN),
else 0.
+ * Caution:
+ *    X is evaluated more than once.
+ */
+#define Py_IS_NAN(X) ((X) != (X))
+
 /* Py_IS_INFINITY(X)
  * Return 1 if float or double arg is an infinity, else 0.
  * Caution:
===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Objects/floatobject.c
--- Objects/floatobject.c	2003/06/28 20:04:24	2.3.3.0
+++ Objects/floatobject.c	2004/02/19 06:03:37
@@ -367,7 +367,21 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	int c;
+	/* Because of NaNs IEEE arithmetic is not a total order.
+	 * Python works better with total orders, so use the same
+	 * total order that GNU sort does: NaNs sort before numbers,
+	 * and NaNs are sorted by internal bit-pattern.
+	 */
+	return ((i < j) ? -1
+		: (i > j) ? 1
+		: (i == j) ? 0
+		: !Py_IS_NAN(j) ? -1 /* i is NaN, j is not */
+		: !Py_IS_NAN(i) ? 1  /* j is NAN, i is not */
+		: /* i and j are both NaNs; compare them bitwise */
+		  ((c = memcmp(&v->ob_fval, &w->ob_fval, sizeof(v->ob_fval)))
+		   < 0) ? -1
+		: (c > 0));
 }
 
 static long


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-18 17:46

Message:
Logged In: YES 
user_id=6656

Man, that's strange (I see the same behaviour on my redhat 9
box with 2.3.3).

I don't have time to dig right now, but if you want to,
playing with equivalent C programs would be a very good start.

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

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

From noreply at sourceforge.net  Thu Feb 19 14:55:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 14:57:14 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1AtuGp-0008WE-00@sc8-sf-web1.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 21:47
Message generated for change (Comment added) made by eggert
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Arman Bostani (arman0)
Assigned to: Michael Hudson (mwh)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float('nan') evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 19:55

Message:
Logged In: YES 
user_id=17848

C99 does say what happens when NaNs are
compared.  See, for example, section 7.12.14,
which says that NaNs are unordered with respect
to other floating point values, and section
7.12.14.1, which says that x>y is equivalent to
isgreater(x,y) and therefore returns false if
either x or y is a NaN (unless the "invalid"
floating-point exception occurs, which isn't
happening here and even if it did happen the
original code would be broken anyway).

Your argument is that any code that uses NaNs
returns garbage and so we should give up.  But
then you have no logical reason to either favor
or oppose this patch, as it doesn't alter
Python's behavior on non-NaN arguments.

It's clear the the patch does fix the comparison
problem on most existing platforms.  It actually
works on Solaris sparc, and I'm sure that it
will work on a wide variety of other important
platforms.

The fact that you've found an incompatibility
between MSVC 6 and C99 on one example does not
mean that the proposed patch won't work: it
merely means that MSVC 6 won't work on your
example (which is deliberately constructed to
confuse pre-C99 compilers).  The proposed patch
doesn't contain confusing code like that, so it
should work even on pre-C99 compilers.

I'm not speaking just from theory here.  Similar
code has been in GNU sort since 1999, and it
works fine in practice.

Since the patch fixes the bug on many (perhaps
all) real platforms, and it can't introduce a
bug on any platform, the patch is a win.

Michael Hudson said "Consider the attached."
but nothing was attached.  I gather from his
comments that he added rich comparisons for
floats.  This will work if the code never
invokes the 2.3.3 float_compare -- so can I take
it that he removed float_compare?


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:39

Message:
Logged In: YES 
user_id=6656

Tim said yes.

Objects/floatobject.c revision 2.127
Misc/NEWS revision 1.936

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:01

Message:
Logged In: YES 
user_id=6656

Consider the attached.  It implements rich comparisons for
floats, which makes the behaviour on linux at least very
much less silly.  All tests except for the
considered-hopeless-on-this box audio tests and the new
test_tcl pass.  Even test_bsddb passed! Twice!  (I'm not
sure I can claim credit for this :-)

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 17:34

Message:
Logged In: YES 
user_id=31435

Sorry, the patch can't work:  C89 says nothing about what 
happens when NaNs are compared, and it's in fact not the 
case across platforms that "x != x" returns 1 when x is a NaN.

The most important counter-example for Python is that the 
following prints

1.#INF
-1.#IND
1

under MSVC 6.

#include <stdio.h>

void main()
{
    double x = 1e300 * 1e300;
    printf("%g\n", x);
    x -= x;
    printf("%g\n", x);
    printf("%d\n", x == x);
}


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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 06:39

Message:
Logged In: YES 
user_id=17848

There's an easy fix.  Python has long mishandled IEEE
special values
(see bugs 445484 and 737648, and see PEP 42 "Non-accidental
IEEE-754
support" as well as PEP 754), and solving the problem in
general will
be some work.  However, solving the NaN-comparison problem
is easy:
simply sort NaNs consistently before all numbers.  This is
the same
algorithm that GNU "sort -g" has used for quite some time.

===================================================================
RCS file: Include/pyport.h,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Include/pyport.h
--- Include/pyport.h	2003/09/30 14:56:50	2.3.3.0
+++ Include/pyport.h	2004/02/19 06:06:10
@@ -221,6 +221,13 @@ extern "C" {
 #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
 #endif
 
+/* Py_IS_NAN(X)
+ * Return 1 if float or double arg is not a number (NaN),
else 0.
+ * Caution:
+ *    X is evaluated more than once.
+ */
+#define Py_IS_NAN(X) ((X) != (X))
+
 /* Py_IS_INFINITY(X)
  * Return 1 if float or double arg is an infinity, else 0.
  * Caution:
===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Objects/floatobject.c
--- Objects/floatobject.c	2003/06/28 20:04:24	2.3.3.0
+++ Objects/floatobject.c	2004/02/19 06:03:37
@@ -367,7 +367,21 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	int c;
+	/* Because of NaNs IEEE arithmetic is not a total order.
+	 * Python works better with total orders, so use the same
+	 * total order that GNU sort does: NaNs sort before numbers,
+	 * and NaNs are sorted by internal bit-pattern.
+	 */
+	return ((i < j) ? -1
+		: (i > j) ? 1
+		: (i == j) ? 0
+		: !Py_IS_NAN(j) ? -1 /* i is NaN, j is not */
+		: !Py_IS_NAN(i) ? 1  /* j is NAN, i is not */
+		: /* i and j are both NaNs; compare them bitwise */
+		  ((c = memcmp(&v->ob_fval, &w->ob_fval, sizeof(v->ob_fval)))
+		   < 0) ? -1
+		: (c > 0));
 }
 
 static long


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-18 17:46

Message:
Logged In: YES 
user_id=6656

Man, that's strange (I see the same behaviour on my redhat 9
box with 2.3.3).

I don't have time to dig right now, but if you want to,
playing with equivalent C programs would be a very good start.

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

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

From noreply at sourceforge.net  Thu Feb 19 14:59:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 15:01:05 2004
Subject: [ python-Bugs-900580 ] IDLE docs broken on OSX
Message-ID: <E1AtuKc-0000FK-00@sc8-sf-web1.sourceforge.net>

Bugs item #900580, was opened at 2004-02-19 14:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900580&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Brandmeyer (jbrandmeyer)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE docs broken on OSX

Initial Comment:
Under Apple's OSX operating system, the variable
sys.platform is named'darwin'.  In at least one place,
idle makes a test to see if thecurrent platform is MS
Windows by checking for the substring 'win'
insys.platform, which leads to incorrect behavior on
the Mac.

In particular, in
lib/python2.3/idlelib/EditorWindow.py, member function
EditorWindow.python_docs() behaves incorrectly on OS X.
 I believe that if the test for MS Windows is
completely removed that you will get correct behavior
on all platforms, based on my reading of the webbrowser
module source.

Please change that function to the following (near line
313):    

>>>    def python_docs(self, event=None):
>>>        webbrowser.open(self.help_url)
>>>        return "break"


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

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

From noreply at sourceforge.net  Thu Feb 19 15:22:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 15:23:48 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1AtugT-0000By-00@sc8-sf-web2.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 16:47
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Arman Bostani (arman0)
Assigned to: Michael Hudson (mwh)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float('nan') evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-19 15:22

Message:
Logged In: YES 
user_id=31435

I specifically said C89.  Python doesn't require C99 support, 
and can't yet, because the majority of compilers used to 
compile Python aren't yet C99 compilers.  Even in C99, that x!
=x is 1 for NaN is optional behavior, depending on whether the 
implementation chooses to define __STDC_IEC_559__.

The point of my example was solely the result of x==x.  It 
doesn't matter how a NaN got put into x, MSVC 6 generates 
code that returns true regardless.  It wasn't constructed to 
confuse anything -- to the contrary, it shows about the most 
straightforward way to *get* a NaN under MSVC 6, short of 
playing tricks with bit representation.

Michael's patch is a more efficient approach regardless.  If 
Python is to grow an isnan macro (which his patch doesn't 
need), then it shoiuld grow an isnan() macro that works on all 
platforms with 754 HW (else it appears to promise thing it 
can't deliver).

Going on to call NaN "less than" everything else goes beyond 
anything C99 says, and is a debate of its own.

No, he didn't remove float_compare().  He could, but only cmp
() will invoke it now.

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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 14:55

Message:
Logged In: YES 
user_id=17848

C99 does say what happens when NaNs are
compared.  See, for example, section 7.12.14,
which says that NaNs are unordered with respect
to other floating point values, and section
7.12.14.1, which says that x>y is equivalent to
isgreater(x,y) and therefore returns false if
either x or y is a NaN (unless the "invalid"
floating-point exception occurs, which isn't
happening here and even if it did happen the
original code would be broken anyway).

Your argument is that any code that uses NaNs
returns garbage and so we should give up.  But
then you have no logical reason to either favor
or oppose this patch, as it doesn't alter
Python's behavior on non-NaN arguments.

It's clear the the patch does fix the comparison
problem on most existing platforms.  It actually
works on Solaris sparc, and I'm sure that it
will work on a wide variety of other important
platforms.

The fact that you've found an incompatibility
between MSVC 6 and C99 on one example does not
mean that the proposed patch won't work: it
merely means that MSVC 6 won't work on your
example (which is deliberately constructed to
confuse pre-C99 compilers).  The proposed patch
doesn't contain confusing code like that, so it
should work even on pre-C99 compilers.

I'm not speaking just from theory here.  Similar
code has been in GNU sort since 1999, and it
works fine in practice.

Since the patch fixes the bug on many (perhaps
all) real platforms, and it can't introduce a
bug on any platform, the patch is a win.

Michael Hudson said "Consider the attached."
but nothing was attached.  I gather from his
comments that he added rich comparisons for
floats.  This will work if the code never
invokes the 2.3.3 float_compare -- so can I take
it that he removed float_compare?


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 14:39

Message:
Logged In: YES 
user_id=6656

Tim said yes.

Objects/floatobject.c revision 2.127
Misc/NEWS revision 1.936

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 14:01

Message:
Logged In: YES 
user_id=6656

Consider the attached.  It implements rich comparisons for
floats, which makes the behaviour on linux at least very
much less silly.  All tests except for the
considered-hopeless-on-this box audio tests and the new
test_tcl pass.  Even test_bsddb passed! Twice!  (I'm not
sure I can claim credit for this :-)

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 12:34

Message:
Logged In: YES 
user_id=31435

Sorry, the patch can't work:  C89 says nothing about what 
happens when NaNs are compared, and it's in fact not the 
case across platforms that "x != x" returns 1 when x is a NaN.

The most important counter-example for Python is that the 
following prints

1.#INF
-1.#IND
1

under MSVC 6.

#include <stdio.h>

void main()
{
    double x = 1e300 * 1e300;
    printf("%g\n", x);
    x -= x;
    printf("%g\n", x);
    printf("%d\n", x == x);
}


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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 01:39

Message:
Logged In: YES 
user_id=17848

There's an easy fix.  Python has long mishandled IEEE
special values
(see bugs 445484 and 737648, and see PEP 42 "Non-accidental
IEEE-754
support" as well as PEP 754), and solving the problem in
general will
be some work.  However, solving the NaN-comparison problem
is easy:
simply sort NaNs consistently before all numbers.  This is
the same
algorithm that GNU "sort -g" has used for quite some time.

===================================================================
RCS file: Include/pyport.h,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Include/pyport.h
--- Include/pyport.h	2003/09/30 14:56:50	2.3.3.0
+++ Include/pyport.h	2004/02/19 06:06:10
@@ -221,6 +221,13 @@ extern "C" {
 #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
 #endif
 
+/* Py_IS_NAN(X)
+ * Return 1 if float or double arg is not a number (NaN),
else 0.
+ * Caution:
+ *    X is evaluated more than once.
+ */
+#define Py_IS_NAN(X) ((X) != (X))
+
 /* Py_IS_INFINITY(X)
  * Return 1 if float or double arg is an infinity, else 0.
  * Caution:
===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Objects/floatobject.c
--- Objects/floatobject.c	2003/06/28 20:04:24	2.3.3.0
+++ Objects/floatobject.c	2004/02/19 06:03:37
@@ -367,7 +367,21 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	int c;
+	/* Because of NaNs IEEE arithmetic is not a total order.
+	 * Python works better with total orders, so use the same
+	 * total order that GNU sort does: NaNs sort before numbers,
+	 * and NaNs are sorted by internal bit-pattern.
+	 */
+	return ((i < j) ? -1
+		: (i > j) ? 1
+		: (i == j) ? 0
+		: !Py_IS_NAN(j) ? -1 /* i is NaN, j is not */
+		: !Py_IS_NAN(i) ? 1  /* j is NAN, i is not */
+		: /* i and j are both NaNs; compare them bitwise */
+		  ((c = memcmp(&v->ob_fval, &w->ob_fval, sizeof(v->ob_fval)))
+		   < 0) ? -1
+		: (c > 0));
 }
 
 static long


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-18 12:46

Message:
Logged In: YES 
user_id=6656

Man, that's strange (I see the same behaviour on my redhat 9
box with 2.3.3).

I don't have time to dig right now, but if you want to,
playing with equivalent C programs would be a very good start.

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

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

From noreply at sourceforge.net  Thu Feb 19 15:45:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 19 15:46:48 2004
Subject: [ python-Bugs-900626 ] add logging.shutdown() to python logging
	module example code
Message-ID: <E1Atv2f-0001Tz-00@sc8-sf-web2.sourceforge.net>

Bugs item #900626, was opened at 2004-02-19 12:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900626&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Manuel Schulte (manuel)
Assigned to: Nobody/Anonymous (nobody)
Summary: add logging.shutdown() to python logging module example code

Initial Comment:
Hi There,

I was trying to get logging with the logging module
working using code from the example provided in section
6.28.8.1 in the documentation.  My log file was empty
after program execution completed.  I ended up adding
'logging.shutdown()' to the end of the example code to
finally see the results in the file ('hdlr.close()'
works as well).

cheers,
manuel






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

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

From noreply at sourceforge.net  Fri Feb 20 01:51:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 01:52:42 2004
Subject: [ python-Bugs-900898 ] urllib2 AuthHandlers can pass a bad host to
	HTTPPasswordMgr
Message-ID: <E1Au4V7-0001tQ-00@sc8-sf-web1.sourceforge.net>

Bugs item #900898, was opened at 2004-02-20 01:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900898&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: James Kruth (jk7)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr

Initial Comment:
If the Request object being used returns a URI with a
port included (e.g. http://www.mysite.com:7777/index.html)

If Request.get_full_url() or Request.get_host() returns
a URI or host with a port included (e.g.
http://www.mysite.com:7777/index.html or
www.mysite.com:7777, respectively), and authentication
(proxy or http, basic only) is required, then the
respective AuthHandlers (HTTPBasicAuthHandler,
ProxyBasicAuthHandler) end up calling
http_error_auth_reqed with a host looking like
"www.mysite.com:7777".  http_error_auth_reqed then
precedes to call retry_http_basic_auth with the same
host parameter, which in turn calls
HTTPPasswordMgr.find_user_password.  The problem is
that find_user_password appears to expect a full URI,
and attempts to reduce it to just a host, by calling
reduce_uri.  If a bare host with a port is passed (like
"www.mysite.com:7777"), then reduce_uri returns just
the port number in the netloc position - which
find_user_password then attempts to compare against the
correct host name you've stored in your HTTPPasswordMgr
object along with your user name and password.  I
believe either find_user_password should not reduce the
host, or the  Auth Handler objects should pass full
hostnames to find_user_password.

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

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

From noreply at sourceforge.net  Fri Feb 20 03:52:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 03:53:44 2004
Subject: [ python-Bugs-900949 ] plat-mac/videoreader.py not working on OS X
Message-ID: <E1Au6OA-0004JF-00@sc8-sf-web2.sourceforge.net>

Bugs item #900949, was opened at 2004-02-20 08:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900949&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Dinu C. Gherman (dinu_gherman)
Assigned to: Jack Jansen (jackjansen)
Summary: plat-mac/videoreader.py not working on OS X

Initial Comment:
plat-mac/videoreader.py uses modules like "img" which 
used to be in Mac OS 9 builds, but are no longer in OS X 
builds. I suggest replacing the pieces with code writing 
images using PIL, if available.

The critical new pieces (whithout checks for PIL) in methods 
ReadVideo/_getpixmapcontent are:

#-----------------------------
from PIL import Image
...
# convert from ARGB to RGBA (faster/better anyone?)
data = []
for i in xrange(0, width*height*4, 4):
        a, r, g, b = rv[i:i+4]
        data.append(r + g + b + a)
data = ''.join(data)
# save image using PIL
img = Image.fromstring("RGBA", (width, height), data)
img.save(<<some filename>>+".jpg", "JPEG")
#-----------------------------

See also my posting on the pythonmac list and its attached 
script:

http://mail.python.org/pipermail/pythonmac-sig/2004-
February/010282.html

or see the attached file (which does not do exactly the same 
as videoreader.py!)...

Dinu

PS: This is on Py 2.3.3 on Mac OS X 10.2.8...

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

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

From noreply at sourceforge.net  Fri Feb 20 04:52:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 04:54:10 2004
Subject: [ python-Bugs-900977 ] cygwinccompiler.get_versions fails on `ld
	-v` output
Message-ID: <E1Au7Kl-0002Yk-00@sc8-sf-web1.sourceforge.net>

Bugs item #900977, was opened at 2004-02-20 11:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900977&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Pearu Peterson (pearu)
Assigned to: Nobody/Anonymous (nobody)
Summary: cygwinccompiler.get_versions fails on `ld -v` output

Initial Comment:
Under linux `ld -v` returns
  GNU ld version 2.14.90.0.7 20031029 Debian GNU/Linux
for instance, and get_versions() function uses
StrictVersion
on '2.14.90.0.7'. This situation triggers an error:
  ValueError: invalid version number '2.14.90.0.7'

As a fix, either use LooseVersion or the following re
pattern
  result = re.search('(\d+\.\d+(\.\d+)?)',out_string)
in `if ld_exe` block.

Pearu

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

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

From noreply at sourceforge.net  Fri Feb 20 06:09:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 06:11:17 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1Au8XI-0002Zb-00@sc8-sf-web3.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 21:47
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Arman Bostani (arman0)
Assigned to: Michael Hudson (mwh)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float('nan') evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

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

>Comment By: Michael Hudson (mwh)
Date: 2004-02-20 11:09

Message:
Logged In: YES 
user_id=6656

Paul, I appreciate your attention to detail, but your last
comment is essentially a rant that puts words into Tim's and
my mouth.

My patch (which is what got checked in) *is* attached to
this report, or you can see it on the python-checkins list.
 There was some ancillary discussion on python-dev (under
the admittedly inscrutable title of "Weekly Python Bug/Patch
Summary") about this, where it was uncovered that MSVC 7.1
(which is what Python 2.4 will be compiled with) adheres to
the C99 rules for comparisons involving NaNs.  So with my
patch, on all major platforms, float comparisons are likely
to follow C99 rules in Python 2.4.  We're still not going to
promise anything, though.

I admit to not doing much research on whether I should/could
remove float_compare.  It seems that perhaps I should.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 20:22

Message:
Logged In: YES 
user_id=31435

I specifically said C89.  Python doesn't require C99 support, 
and can't yet, because the majority of compilers used to 
compile Python aren't yet C99 compilers.  Even in C99, that x!
=x is 1 for NaN is optional behavior, depending on whether the 
implementation chooses to define __STDC_IEC_559__.

The point of my example was solely the result of x==x.  It 
doesn't matter how a NaN got put into x, MSVC 6 generates 
code that returns true regardless.  It wasn't constructed to 
confuse anything -- to the contrary, it shows about the most 
straightforward way to *get* a NaN under MSVC 6, short of 
playing tricks with bit representation.

Michael's patch is a more efficient approach regardless.  If 
Python is to grow an isnan macro (which his patch doesn't 
need), then it shoiuld grow an isnan() macro that works on all 
platforms with 754 HW (else it appears to promise thing it 
can't deliver).

Going on to call NaN "less than" everything else goes beyond 
anything C99 says, and is a debate of its own.

No, he didn't remove float_compare().  He could, but only cmp
() will invoke it now.

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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 19:55

Message:
Logged In: YES 
user_id=17848

C99 does say what happens when NaNs are
compared.  See, for example, section 7.12.14,
which says that NaNs are unordered with respect
to other floating point values, and section
7.12.14.1, which says that x>y is equivalent to
isgreater(x,y) and therefore returns false if
either x or y is a NaN (unless the "invalid"
floating-point exception occurs, which isn't
happening here and even if it did happen the
original code would be broken anyway).

Your argument is that any code that uses NaNs
returns garbage and so we should give up.  But
then you have no logical reason to either favor
or oppose this patch, as it doesn't alter
Python's behavior on non-NaN arguments.

It's clear the the patch does fix the comparison
problem on most existing platforms.  It actually
works on Solaris sparc, and I'm sure that it
will work on a wide variety of other important
platforms.

The fact that you've found an incompatibility
between MSVC 6 and C99 on one example does not
mean that the proposed patch won't work: it
merely means that MSVC 6 won't work on your
example (which is deliberately constructed to
confuse pre-C99 compilers).  The proposed patch
doesn't contain confusing code like that, so it
should work even on pre-C99 compilers.

I'm not speaking just from theory here.  Similar
code has been in GNU sort since 1999, and it
works fine in practice.

Since the patch fixes the bug on many (perhaps
all) real platforms, and it can't introduce a
bug on any platform, the patch is a win.

Michael Hudson said "Consider the attached."
but nothing was attached.  I gather from his
comments that he added rich comparisons for
floats.  This will work if the code never
invokes the 2.3.3 float_compare -- so can I take
it that he removed float_compare?


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:39

Message:
Logged In: YES 
user_id=6656

Tim said yes.

Objects/floatobject.c revision 2.127
Misc/NEWS revision 1.936

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:01

Message:
Logged In: YES 
user_id=6656

Consider the attached.  It implements rich comparisons for
floats, which makes the behaviour on linux at least very
much less silly.  All tests except for the
considered-hopeless-on-this box audio tests and the new
test_tcl pass.  Even test_bsddb passed! Twice!  (I'm not
sure I can claim credit for this :-)

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 17:34

Message:
Logged In: YES 
user_id=31435

Sorry, the patch can't work:  C89 says nothing about what 
happens when NaNs are compared, and it's in fact not the 
case across platforms that "x != x" returns 1 when x is a NaN.

The most important counter-example for Python is that the 
following prints

1.#INF
-1.#IND
1

under MSVC 6.

#include <stdio.h>

void main()
{
    double x = 1e300 * 1e300;
    printf("%g\n", x);
    x -= x;
    printf("%g\n", x);
    printf("%d\n", x == x);
}


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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 06:39

Message:
Logged In: YES 
user_id=17848

There's an easy fix.  Python has long mishandled IEEE
special values
(see bugs 445484 and 737648, and see PEP 42 "Non-accidental
IEEE-754
support" as well as PEP 754), and solving the problem in
general will
be some work.  However, solving the NaN-comparison problem
is easy:
simply sort NaNs consistently before all numbers.  This is
the same
algorithm that GNU "sort -g" has used for quite some time.

===================================================================
RCS file: Include/pyport.h,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Include/pyport.h
--- Include/pyport.h	2003/09/30 14:56:50	2.3.3.0
+++ Include/pyport.h	2004/02/19 06:06:10
@@ -221,6 +221,13 @@ extern "C" {
 #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
 #endif
 
+/* Py_IS_NAN(X)
+ * Return 1 if float or double arg is not a number (NaN),
else 0.
+ * Caution:
+ *    X is evaluated more than once.
+ */
+#define Py_IS_NAN(X) ((X) != (X))
+
 /* Py_IS_INFINITY(X)
  * Return 1 if float or double arg is an infinity, else 0.
  * Caution:
===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Objects/floatobject.c
--- Objects/floatobject.c	2003/06/28 20:04:24	2.3.3.0
+++ Objects/floatobject.c	2004/02/19 06:03:37
@@ -367,7 +367,21 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	int c;
+	/* Because of NaNs IEEE arithmetic is not a total order.
+	 * Python works better with total orders, so use the same
+	 * total order that GNU sort does: NaNs sort before numbers,
+	 * and NaNs are sorted by internal bit-pattern.
+	 */
+	return ((i < j) ? -1
+		: (i > j) ? 1
+		: (i == j) ? 0
+		: !Py_IS_NAN(j) ? -1 /* i is NaN, j is not */
+		: !Py_IS_NAN(i) ? 1  /* j is NAN, i is not */
+		: /* i and j are both NaNs; compare them bitwise */
+		  ((c = memcmp(&v->ob_fval, &w->ob_fval, sizeof(v->ob_fval)))
+		   < 0) ? -1
+		: (c > 0));
 }
 
 static long


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-18 17:46

Message:
Logged In: YES 
user_id=6656

Man, that's strange (I see the same behaviour on my redhat 9
box with 2.3.3).

I don't have time to dig right now, but if you want to,
playing with equivalent C programs would be a very good start.

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

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

From noreply at sourceforge.net  Fri Feb 20 09:39:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 10:03:38 2004
Subject: [ python-Bugs-900898 ] urllib2 AuthHandlers can pass a bad host to
	HTTPPasswordMgr
Message-ID: <E1AuBoD-0005ko-00@sc8-sf-web3.sourceforge.net>

Bugs item #900898, was opened at 2004-02-20 01:51
Message generated for change (Comment added) made by jk7
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900898&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: James Kruth (jk7)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr

Initial Comment:
If the Request object being used returns a URI with a
port included (e.g. http://www.mysite.com:7777/index.html)

If Request.get_full_url() or Request.get_host() returns
a URI or host with a port included (e.g.
http://www.mysite.com:7777/index.html or
www.mysite.com:7777, respectively), and authentication
(proxy or http, basic only) is required, then the
respective AuthHandlers (HTTPBasicAuthHandler,
ProxyBasicAuthHandler) end up calling
http_error_auth_reqed with a host looking like
"www.mysite.com:7777".  http_error_auth_reqed then
precedes to call retry_http_basic_auth with the same
host parameter, which in turn calls
HTTPPasswordMgr.find_user_password.  The problem is
that find_user_password appears to expect a full URI,
and attempts to reduce it to just a host, by calling
reduce_uri.  If a bare host with a port is passed (like
"www.mysite.com:7777"), then reduce_uri returns just
the port number in the netloc position - which
find_user_password then attempts to compare against the
correct host name you've stored in your HTTPPasswordMgr
object along with your user name and password.  I
believe either find_user_password should not reduce the
host, or the  Auth Handler objects should pass full
hostnames to find_user_password.

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

>Comment By: James Kruth (jk7)
Date: 2004-02-20 09:39

Message:
Logged In: YES 
user_id=979977

I've made up a file with some source code and comments that
will hopefully clarify what I posted.  I will post an
example of the problem a bit later today.

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

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

From noreply at sourceforge.net  Fri Feb 20 11:47:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 11:49:17 2004
Subject: [ python-Bugs-901198 ] strange behaviour of xmlrpclib.Server proxy
Message-ID: <E1AuDoP-00018h-00@sc8-sf-web4.sourceforge.net>

Bugs item #901198, was opened at 2004-02-20 16:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901198&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Eisele (eisele)
Assigned to: Nobody/Anonymous (nobody)
Summary: strange behaviour of xmlrpclib.Server proxy

Initial Comment:
Not quite sure this is a bug, but the problem caused me 
considerable time to track down (Python 2.3.2 on Solaris).

assume proxy is a variable for a server proxy created with
xmlrpclib.Server(), but sometimes it is None (assume a
default argument to a function).

The comparisons

if proxy != None:

or

if proxy:

fail with (to me) rather incomprehensible error messages.

However, the test

if proxy is not None:

does what I expect.

Is this a feature or a bug?


Thanks a lot for looking into it.

Andreas Eisele

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

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

From noreply at sourceforge.net  Fri Feb 20 12:56:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 12:58:40 2004
Subject: [ python-Bugs-842170 ] logging.shutdown() exception
Message-ID: <E1AuEtP-0004oI-00@sc8-sf-web4.sourceforge.net>

Bugs item #842170, was opened at 2003-11-14 15:38
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842170&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: j vickroy (jvickroy)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.shutdown() exception

Initial Comment:
Python version:
Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32

Operating System:
MS Windows 2000 Professional with all latest patches

Synopsis:

When reassigning a handler (RotatingFileSystem) to a 
logger during execution, close() must be invoked against 
the current handler.  Failure to do so causes the 
following exception to be raised:

 Traceback (most recent call last):
   File
 "C:\Python23\lib\site-
packages\Pythonwin\pywin\framework\scriptutils.py",
 line 310, in RunScript
     exec codeObject in __main__.__dict__
   File "E:\\experimental\Py Logging\t_xc.py", 
line 61, in ?
     log.error('testing Python logging module')
   File "C:\Python23\lib\logging\__init__.py", line 923, in 
error
     apply(self._log, (ERROR, msg, args), kwargs)
   File "C:\Python23\lib\logging\__init__.py", line 994, in 
_log
     self.handle(record)
   File "C:\Python23\lib\logging\__init__.py", line 1004, in 
handle
     self.callHandlers(record)
   File "C:\Python23\lib\logging\__init__.py", line 1037, in 
callHandlers
     hdlr.handle(record)
   File "C:\Python23\lib\logging\__init__.py", line 592, in 
handle
     self.emit(record)
   File "C:\Python23\lib\logging\handlers.py", line 105, in 
emit
     self.doRollover()
   File "C:\Python23\lib\logging\handlers.py", line 90, in 
doRollover
     os.rename(self.baseFilename, dfn)
 OSError: [Errno 13] Permission denied

If close() is applied to each handler, except the final 
assigned handler, then logging.shutdown() raises the 
following exception when it is applied prior to application 
termination:

Traceback (most recent call last):
  File "D:\\experimental\Py Logging\t_xb.py", 
line 63, in ?
    shutdown()
  File "C:\Python23\lib\logging\__init__.py", line 1195, in 
shutdown
    h.flush()
  File "C:\Python23\lib\logging\__init__.py", line 661, in 
flush
    self.stream.flush()
ValueError: I/O operation on closed file

apparently, because it is attempting to close previously-
closed handlers.

Please, see attachment for a relevant script.

If it is agreed that this is an appropriate use of the 
logging system (and I think it is <smile>), I would be 
willing to attempt a patch if that is preferable.

Thanks for your time.

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

>Comment By: Vinay Sajip (vsajip)
Date: 2004-02-20 17:56

Message:
Logged In: YES 
user_id=308438

Problem was caused because shutdown() tried to close 
already closed handlers.

Solved by close() removing handler from an internal list which 
is used by shutdown().

Fixed in CVS.


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

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

From noreply at sourceforge.net  Fri Feb 20 14:27:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 14:29:09 2004
Subject: [ python-Bugs-901285 ] random.randint fails for some ranges
Message-ID: <E1AuGJ8-0003kP-00@sc8-sf-web1.sourceforge.net>

Bugs item #901285, was opened at 2004-02-20 19:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901285&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.randint fails for some ranges

Initial Comment:
I want a random 32-bit int and do it the obvious way:

lowest, highest = int(-2**31), int(2**31-1)
r = random.randint(lowest, highest)

random.randint throws an exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/random.py", line 349, in randint
    return self.randrange(a, b+1)
  File "/usr/lib/python2.2/random.py", line 328, in
randrange
    raise ValueError, "empty range for randrange()"
ValueError: empty range for randrange()


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

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

From noreply at sourceforge.net  Fri Feb 20 15:16:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 15:18:28 2004
Subject: [ python-Bugs-901330 ] logging handlers can close without flush
Message-ID: <E1AuH4q-0005u0-00@sc8-sf-web1.sourceforge.net>

Bugs item #901330, was opened at 2004-02-20 15:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901330&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging handlers can close without flush

Initial Comment:
logging.Handler().close() does not call flush().  Some 
derived handlers override this and call flush themselves; 
some do not.  I'm not certain which streams are buffered 
under the hood, but I think it would be fine to call flush in 
all cases.  In particular, I think BufferingHandler should 
always flush, and FileHandler probably should too.

Note that just adding it to Handler().close() would not 
work with the current CVS version, as the derived class 
may call the parent close (to clean up _handlers) after 
closing (and making unflushable) the stream.


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

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

From noreply at sourceforge.net  Fri Feb 20 15:26:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 15:27:41 2004
Subject: [ python-Bugs-900626 ] add logging.shutdown() to python logging
	module example code
Message-ID: <E1AuHDl-0007IG-00@sc8-sf-web3.sourceforge.net>

Bugs item #900626, was opened at 2004-02-19 15:45
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900626&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Manuel Schulte (manuel)
Assigned to: Nobody/Anonymous (nobody)
Summary: add logging.shutdown() to python logging module example code

Initial Comment:
Hi There,

I was trying to get logging with the logging module
working using code from the example provided in section
6.28.8.1 in the documentation.  My log file was empty
after program execution completed.  I ended up adding
'logging.shutdown()' to the end of the example code to
finally see the results in the file ('hdlr.close()'
works as well).

cheers,
manuel






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

Comment By: Jim Jewett (jimjjewett)
Date: 2004-02-20 15:26

Message:
Logged In: YES 
user_id=764593

Correct, but ...

With current code, you want to be sure that you don't call 
shutdown more than once.

With CVS code, you will no longer need to call shutdown 
manually.  So the doco change won't be needed either.

If you just want to hurry the results along, you can call 
hdlr.flush(), which still leaves the handler open for further use.


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

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

From noreply at sourceforge.net  Fri Feb 20 16:10:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 16:13:34 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1AuHv7-0005Mh-00@sc8-sf-web4.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 21:47
Message generated for change (Comment added) made by eggert
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Arman Bostani (arman0)
Assigned to: Michael Hudson (mwh)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float('nan') evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

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

Comment By: Paul Eggert (eggert)
Date: 2004-02-20 21:10

Message:
Logged In: YES 
user_id=17848

Sorry, I didn't intend a rant, and I apologize if any
offense was given.  I'll try to use a milder tone
henceforth.

To answer Michael's question: yes, now that your patch is
installed, float_compare is incompatible with rich
comparison; for example cmp(NaN,1.0) returns 0 even though
NaN==1.0 returns False.

Another problem: cmp() initially uses pointer comparison to
compare objects, so if x is a NaN then cmp(x,x) returns 0.

I don't think that removing float_compare will fix the
problem, as it would simply cause cmp to return an incorrect
value when given a NaN.

If you prefer IEEE semantics to sorting NaNs before numbers,
another possibility is for cmp to raise an exception when
given a NaN, since in that case cmp can't return any value
that is compatible with IEEE floating point.

Here's a patch to implement this proposal.  It does not rely
on isnan or a substitute, so I hope this answers Tim's
objection.  Note that PyObject_Compare needs a minor change,
too; since user-defined types may have the same problem that
Float does, it's simplest just to omit the optimization
there.

===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.2
retrieving revision 2.3.3.3
diff -pu -r2.3.3.2 -r2.3.3.3
--- Objects/floatobject.c	2004/02/20 19:45:01	2.3.3.2
+++ Objects/floatobject.c	2004/02/20 21:04:20	2.3.3.3
@@ -367,7 +367,15 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	if (i < j)
+		return -1;
+	if (i > j)
+		return 1;
+	if (i == j)
+		return 0;
+	PyErr_SetString(PyExc_FloatingPointError,
+			"cannot compare NaNs using cmp");
+	return -2;
 }
 
 static PyObject*
===================================================================
RCS file: Objects/object.c,v
retrieving revision 2.3.3.0
retrieving revision 2.3.3.1
diff -pu -r2.3.3.0 -r2.3.3.1
--- Objects/object.c	2003/04/18 00:45:58	2.3.3.0
+++ Objects/object.c	2004/02/20 21:04:20	2.3.3.1
@@ -877,8 +877,6 @@ PyObject_Compare(PyObject *v, PyObject *
 		PyErr_BadInternalCall();
 		return -1;
 	}
-	if (v == w)
-		return 0;
 	vtp = v->ob_type;
 	compare_nesting++;
 	if (compare_nesting > NESTING_LIMIT &&


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-20 11:09

Message:
Logged In: YES 
user_id=6656

Paul, I appreciate your attention to detail, but your last
comment is essentially a rant that puts words into Tim's and
my mouth.

My patch (which is what got checked in) *is* attached to
this report, or you can see it on the python-checkins list.
 There was some ancillary discussion on python-dev (under
the admittedly inscrutable title of "Weekly Python Bug/Patch
Summary") about this, where it was uncovered that MSVC 7.1
(which is what Python 2.4 will be compiled with) adheres to
the C99 rules for comparisons involving NaNs.  So with my
patch, on all major platforms, float comparisons are likely
to follow C99 rules in Python 2.4.  We're still not going to
promise anything, though.

I admit to not doing much research on whether I should/could
remove float_compare.  It seems that perhaps I should.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 20:22

Message:
Logged In: YES 
user_id=31435

I specifically said C89.  Python doesn't require C99 support, 
and can't yet, because the majority of compilers used to 
compile Python aren't yet C99 compilers.  Even in C99, that x!
=x is 1 for NaN is optional behavior, depending on whether the 
implementation chooses to define __STDC_IEC_559__.

The point of my example was solely the result of x==x.  It 
doesn't matter how a NaN got put into x, MSVC 6 generates 
code that returns true regardless.  It wasn't constructed to 
confuse anything -- to the contrary, it shows about the most 
straightforward way to *get* a NaN under MSVC 6, short of 
playing tricks with bit representation.

Michael's patch is a more efficient approach regardless.  If 
Python is to grow an isnan macro (which his patch doesn't 
need), then it shoiuld grow an isnan() macro that works on all 
platforms with 754 HW (else it appears to promise thing it 
can't deliver).

Going on to call NaN "less than" everything else goes beyond 
anything C99 says, and is a debate of its own.

No, he didn't remove float_compare().  He could, but only cmp
() will invoke it now.

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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 19:55

Message:
Logged In: YES 
user_id=17848

C99 does say what happens when NaNs are
compared.  See, for example, section 7.12.14,
which says that NaNs are unordered with respect
to other floating point values, and section
7.12.14.1, which says that x>y is equivalent to
isgreater(x,y) and therefore returns false if
either x or y is a NaN (unless the "invalid"
floating-point exception occurs, which isn't
happening here and even if it did happen the
original code would be broken anyway).

Your argument is that any code that uses NaNs
returns garbage and so we should give up.  But
then you have no logical reason to either favor
or oppose this patch, as it doesn't alter
Python's behavior on non-NaN arguments.

It's clear the the patch does fix the comparison
problem on most existing platforms.  It actually
works on Solaris sparc, and I'm sure that it
will work on a wide variety of other important
platforms.

The fact that you've found an incompatibility
between MSVC 6 and C99 on one example does not
mean that the proposed patch won't work: it
merely means that MSVC 6 won't work on your
example (which is deliberately constructed to
confuse pre-C99 compilers).  The proposed patch
doesn't contain confusing code like that, so it
should work even on pre-C99 compilers.

I'm not speaking just from theory here.  Similar
code has been in GNU sort since 1999, and it
works fine in practice.

Since the patch fixes the bug on many (perhaps
all) real platforms, and it can't introduce a
bug on any platform, the patch is a win.

Michael Hudson said "Consider the attached."
but nothing was attached.  I gather from his
comments that he added rich comparisons for
floats.  This will work if the code never
invokes the 2.3.3 float_compare -- so can I take
it that he removed float_compare?


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:39

Message:
Logged In: YES 
user_id=6656

Tim said yes.

Objects/floatobject.c revision 2.127
Misc/NEWS revision 1.936

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:01

Message:
Logged In: YES 
user_id=6656

Consider the attached.  It implements rich comparisons for
floats, which makes the behaviour on linux at least very
much less silly.  All tests except for the
considered-hopeless-on-this box audio tests and the new
test_tcl pass.  Even test_bsddb passed! Twice!  (I'm not
sure I can claim credit for this :-)

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 17:34

Message:
Logged In: YES 
user_id=31435

Sorry, the patch can't work:  C89 says nothing about what 
happens when NaNs are compared, and it's in fact not the 
case across platforms that "x != x" returns 1 when x is a NaN.

The most important counter-example for Python is that the 
following prints

1.#INF
-1.#IND
1

under MSVC 6.

#include <stdio.h>

void main()
{
    double x = 1e300 * 1e300;
    printf("%g\n", x);
    x -= x;
    printf("%g\n", x);
    printf("%d\n", x == x);
}


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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 06:39

Message:
Logged In: YES 
user_id=17848

There's an easy fix.  Python has long mishandled IEEE
special values
(see bugs 445484 and 737648, and see PEP 42 "Non-accidental
IEEE-754
support" as well as PEP 754), and solving the problem in
general will
be some work.  However, solving the NaN-comparison problem
is easy:
simply sort NaNs consistently before all numbers.  This is
the same
algorithm that GNU "sort -g" has used for quite some time.

===================================================================
RCS file: Include/pyport.h,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Include/pyport.h
--- Include/pyport.h	2003/09/30 14:56:50	2.3.3.0
+++ Include/pyport.h	2004/02/19 06:06:10
@@ -221,6 +221,13 @@ extern "C" {
 #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
 #endif
 
+/* Py_IS_NAN(X)
+ * Return 1 if float or double arg is not a number (NaN),
else 0.
+ * Caution:
+ *    X is evaluated more than once.
+ */
+#define Py_IS_NAN(X) ((X) != (X))
+
 /* Py_IS_INFINITY(X)
  * Return 1 if float or double arg is an infinity, else 0.
  * Caution:
===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Objects/floatobject.c
--- Objects/floatobject.c	2003/06/28 20:04:24	2.3.3.0
+++ Objects/floatobject.c	2004/02/19 06:03:37
@@ -367,7 +367,21 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	int c;
+	/* Because of NaNs IEEE arithmetic is not a total order.
+	 * Python works better with total orders, so use the same
+	 * total order that GNU sort does: NaNs sort before numbers,
+	 * and NaNs are sorted by internal bit-pattern.
+	 */
+	return ((i < j) ? -1
+		: (i > j) ? 1
+		: (i == j) ? 0
+		: !Py_IS_NAN(j) ? -1 /* i is NaN, j is not */
+		: !Py_IS_NAN(i) ? 1  /* j is NAN, i is not */
+		: /* i and j are both NaNs; compare them bitwise */
+		  ((c = memcmp(&v->ob_fval, &w->ob_fval, sizeof(v->ob_fval)))
+		   < 0) ? -1
+		: (c > 0));
 }
 
 static long


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-18 17:46

Message:
Logged In: YES 
user_id=6656

Man, that's strange (I see the same behaviour on my redhat 9
box with 2.3.3).

I don't have time to dig right now, but if you want to,
playing with equivalent C programs would be a very good start.

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

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

From noreply at sourceforge.net  Fri Feb 20 16:25:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 16:33:18 2004
Subject: [ python-Bugs-900898 ] urllib2 AuthHandlers can pass a bad host to
	HTTPPasswordMgr
Message-ID: <E1AuI9R-0000e2-00@sc8-sf-web1.sourceforge.net>

Bugs item #900898, was opened at 2004-02-20 01:51
Message generated for change (Comment added) made by jk7
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900898&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: James Kruth (jk7)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr

Initial Comment:
If the Request object being used returns a URI with a
port included (e.g. http://www.mysite.com:7777/index.html)

If Request.get_full_url() or Request.get_host() returns
a URI or host with a port included (e.g.
http://www.mysite.com:7777/index.html or
www.mysite.com:7777, respectively), and authentication
(proxy or http, basic only) is required, then the
respective AuthHandlers (HTTPBasicAuthHandler,
ProxyBasicAuthHandler) end up calling
http_error_auth_reqed with a host looking like
"www.mysite.com:7777".  http_error_auth_reqed then
precedes to call retry_http_basic_auth with the same
host parameter, which in turn calls
HTTPPasswordMgr.find_user_password.  The problem is
that find_user_password appears to expect a full URI,
and attempts to reduce it to just a host, by calling
reduce_uri.  If a bare host with a port is passed (like
"www.mysite.com:7777"), then reduce_uri returns just
the port number in the netloc position - which
find_user_password then attempts to compare against the
correct host name you've stored in your HTTPPasswordMgr
object along with your user name and password.  I
believe either find_user_password should not reduce the
host, or the  Auth Handler objects should pass full
hostnames to find_user_password.

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

>Comment By: James Kruth (jk7)
Date: 2004-02-20 16:25

Message:
Logged In: YES 
user_id=979977

Here's a sample of the problem...

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

Comment By: James Kruth (jk7)
Date: 2004-02-20 09:39

Message:
Logged In: YES 
user_id=979977

I've made up a file with some source code and comments that
will hopefully clarify what I posted.  I will post an
example of the problem a bit later today.

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

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

From noreply at sourceforge.net  Fri Feb 20 18:46:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 20 18:47:46 2004
Subject: [ python-Bugs-853506 ] IP6 address parsing i sgmllib
Message-ID: <E1AuKLR-000832-00@sc8-sf-web3.sourceforge.net>

Bugs item #853506, was opened at 2003-12-03 14:15
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=853506&group_id=5470

Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: IP6 address parsing i sgmllib

Initial Comment:
The sgmllib.attrfind regex excludes [ and ].

http://www.ietf.org/rfc/rfc2732.txt uses these in the 
host portion to indicate that an address is IP6 rather 
than IP4.  

http://[1080::8:800:200C:417A]/foo

RFC 2732 is referenced as normative by the xml:base 
module.  I grouped the issue as 2.3, on the assumption 
that it isn't a bug until IP6 is used.


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

>Comment By: Jim Jewett (jimjjewett)
Date: 2004-02-20 18:46

Message:
Logged In: YES 
user_id=764593

Assigned to 2.3 when that was development.  Moved to 2.4 
now, still on the assumption that the bug won't hit with real 
data until IP6 is more common.

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

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

From noreply at sourceforge.net  Sat Feb 21 00:32:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 00:34:36 2004
Subject: [ python-Bugs-901285 ] random.randint fails for some ranges
Message-ID: <E1AuPky-0004iP-00@sc8-sf-web4.sourceforge.net>

Bugs item #901285, was opened at 2004-02-20 19:27
Message generated for change (Settings changed) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901285&group_id=5470

>Category: Python Library
>Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.randint fails for some ranges

Initial Comment:
I want a random 32-bit int and do it the obvious way:

lowest, highest = int(-2**31), int(2**31-1)
r = random.randint(lowest, highest)

random.randint throws an exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/random.py", line 349, in randint
    return self.randrange(a, b+1)
  File "/usr/lib/python2.2/random.py", line 328, in
randrange
    raise ValueError, "empty range for randrange()"
ValueError: empty range for randrange()


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

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

From noreply at sourceforge.net  Sat Feb 21 00:45:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 00:46:53 2004
Subject: [ python-Bugs-901605 ] random.seed not initialized as advertised
Message-ID: <E1AuPws-0002GD-00@sc8-sf-web1.sourceforge.net>

Bugs item #901605, was opened at 2004-02-21 05:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901605&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.seed not initialized as advertised

Initial Comment:
The doc for random.seed(x) says: Optional argument x
can be any hashable object. If x is omitted or None,
current system time is used; current system time is
also used to initialize the generator when the module
is first imported. 

In fact the random module calls the seed function with
x=None when a Random object is instantiated, not with
the current system time as the docs indicate.  You can
tell this by doing something like:

  import random
  class myrand(random.Random):
    def seed(x): 
       print x
       random.Random.seed(x)  
  a = myrand()

and you'll see it prints None.  Initializing with None
may be reasonable behavior, but it doesn't match the
docs.  So either the code or the doc should be updated.


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

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

From noreply at sourceforge.net  Sat Feb 21 02:39:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 02:41:34 2004
Subject: [ python-Bugs-901605 ] random.seed not initialized as advertised
Message-ID: <E1AuRjq-0004yY-00@sc8-sf-web1.sourceforge.net>

Bugs item #901605, was opened at 2004-02-21 00:45
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901605&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.seed not initialized as advertised

Initial Comment:
The doc for random.seed(x) says: Optional argument x
can be any hashable object. If x is omitted or None,
current system time is used; current system time is
also used to initialize the generator when the module
is first imported. 

In fact the random module calls the seed function with
x=None when a Random object is instantiated, not with
the current system time as the docs indicate.  You can
tell this by doing something like:

  import random
  class myrand(random.Random):
    def seed(x): 
       print x
       random.Random.seed(x)  
  a = myrand()

and you'll see it prints None.  Initializing with None
may be reasonable behavior, but it doesn't match the
docs.  So either the code or the doc should be updated.


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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-21 02:39

Message:
Logged In: YES 
user_id=31435

The docs are correct.  They say that calling seed() with no 
argument is the same as calling seed(None), and that's true, 
and it's also true that both cases end up using current 
system time.  That happens because the implementation of 
seed() special-cases argument None, but the docs describe 
behavior, not implementation details.

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

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

From noreply at sourceforge.net  Sat Feb 21 02:46:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 02:47:54 2004
Subject: [ python-Bugs-901605 ] random.seed not initialized as advertised
Message-ID: <E1AuRq3-0004p1-00@sc8-sf-web3.sourceforge.net>

Bugs item #901605, was opened at 2004-02-21 00:45
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901605&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: random.seed not initialized as advertised

Initial Comment:
The doc for random.seed(x) says: Optional argument x
can be any hashable object. If x is omitted or None,
current system time is used; current system time is
also used to initialize the generator when the module
is first imported. 

In fact the random module calls the seed function with
x=None when a Random object is instantiated, not with
the current system time as the docs indicate.  You can
tell this by doing something like:

  import random
  class myrand(random.Random):
    def seed(x): 
       print x
       random.Random.seed(x)  
  a = myrand()

and you'll see it prints None.  Initializing with None
may be reasonable behavior, but it doesn't match the
docs.  So either the code or the doc should be updated.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 02:46

Message:
Logged In: YES 
user_id=80475

I believe you are misreading the docs.  They describe what
Random.seed() DOES with the arguments, not HOW it is called.

The code for seed() shows that if the argument is None, it
calls time.time() and uses that as the seed value:

"""
        if a is None:
            # Initialize from current time
            import time
            a = long(time.time() * 256)

        if type(a) not in (type(3), type(3L)):
            a = hash(a)

        a, x = divmod(a, 30268)
        a, y = divmod(a, 30306)
        a, z = divmod(a, 30322)
        self._seed = int(x)+1, int(y)+1, int(z)+1

        self.gauss_next = None
"""

I understand that this behavior (which DOES match the
documentation) may be inconvenient if you override the
seed() method.  You are pretty much forced to add a few
lines of code to replicate seed's documented behavior.

If the module were being rewritten from scratch, this
behavior would be factored out.  However, it has been this
way since the dawn of time and is not sufficiently painful
to warrant a change.  Or, more accurately put, changing it
would cause more discomfort than it would save (i.e. the
huge existing code base takes priority here).

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 02:39

Message:
Logged In: YES 
user_id=31435

The docs are correct.  They say that calling seed() with no 
argument is the same as calling seed(None), and that's true, 
and it's also true that both cases end up using current 
system time.  That happens because the implementation of 
seed() special-cases argument None, but the docs describe 
behavior, not implementation details.

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

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

From noreply at sourceforge.net  Sat Feb 21 02:52:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 02:54:07 2004
Subject: [ python-Bugs-901605 ] random.seed not initialized as advertised
Message-ID: <E1AuRvz-0005Fr-00@sc8-sf-web1.sourceforge.net>

Bugs item #901605, was opened at 2004-02-21 05:45
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901605&group_id=5470

>Category: Documentation
Group: Python 2.2.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.seed not initialized as advertised

Initial Comment:
The doc for random.seed(x) says: Optional argument x
can be any hashable object. If x is omitted or None,
current system time is used; current system time is
also used to initialize the generator when the module
is first imported. 

In fact the random module calls the seed function with
x=None when a Random object is instantiated, not with
the current system time as the docs indicate.  You can
tell this by doing something like:

  import random
  class myrand(random.Random):
    def seed(x): 
       print x
       random.Random.seed(x)  
  a = myrand()

and you'll see it prints None.  Initializing with None
may be reasonable behavior, but it doesn't match the
docs.  So either the code or the doc should be updated.


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

>Comment By: paul rubin (phr)
Date: 2004-02-21 07:52

Message:
Logged In: YES 
user_id=72053

If that's what the docs are trying to say, they're unclear
and should be updated.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 07:46

Message:
Logged In: YES 
user_id=80475

I believe you are misreading the docs.  They describe what
Random.seed() DOES with the arguments, not HOW it is called.

The code for seed() shows that if the argument is None, it
calls time.time() and uses that as the seed value:

"""
        if a is None:
            # Initialize from current time
            import time
            a = long(time.time() * 256)

        if type(a) not in (type(3), type(3L)):
            a = hash(a)

        a, x = divmod(a, 30268)
        a, y = divmod(a, 30306)
        a, z = divmod(a, 30322)
        self._seed = int(x)+1, int(y)+1, int(z)+1

        self.gauss_next = None
"""

I understand that this behavior (which DOES match the
documentation) may be inconvenient if you override the
seed() method.  You are pretty much forced to add a few
lines of code to replicate seed's documented behavior.

If the module were being rewritten from scratch, this
behavior would be factored out.  However, it has been this
way since the dawn of time and is not sufficiently painful
to warrant a change.  Or, more accurately put, changing it
would cause more discomfort than it would save (i.e. the
huge existing code base takes priority here).

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 07:39

Message:
Logged In: YES 
user_id=31435

The docs are correct.  They say that calling seed() with no 
argument is the same as calling seed(None), and that's true, 
and it's also true that both cases end up using current 
system time.  That happens because the implementation of 
seed() special-cases argument None, but the docs describe 
behavior, not implementation details.

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

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

From noreply at sourceforge.net  Sat Feb 21 02:54:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 02:56:09 2004
Subject: [ python-Bugs-901605 ] random.seed not initialized as advertised
Message-ID: <E1AuRy3-00050X-00@sc8-sf-web3.sourceforge.net>

Bugs item #901605, was opened at 2004-02-21 00:45
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901605&group_id=5470

>Category: Python Library
Group: Python 2.2.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.seed not initialized as advertised

Initial Comment:
The doc for random.seed(x) says: Optional argument x
can be any hashable object. If x is omitted or None,
current system time is used; current system time is
also used to initialize the generator when the module
is first imported. 

In fact the random module calls the seed function with
x=None when a Random object is instantiated, not with
the current system time as the docs indicate.  You can
tell this by doing something like:

  import random
  class myrand(random.Random):
    def seed(x): 
       print x
       random.Random.seed(x)  
  a = myrand()

and you'll see it prints None.  Initializing with None
may be reasonable behavior, but it doesn't match the
docs.  So either the code or the doc should be updated.


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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-21 02:54

Message:
Logged In: YES 
user_id=31435

I don't believe we'd change this behavior -- it's intentional 
that the default seeding varies each time you run a program.  
Subclasses aren't an argument against this:  a subclass isn't 
required to mimic a base class's behavior in all respects.  If it 
were, there would be darn little point to having subclasses 
<wink>.

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

Comment By: paul rubin (phr)
Date: 2004-02-21 02:52

Message:
Logged In: YES 
user_id=72053

If that's what the docs are trying to say, they're unclear
and should be updated.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 02:46

Message:
Logged In: YES 
user_id=80475

I believe you are misreading the docs.  They describe what
Random.seed() DOES with the arguments, not HOW it is called.

The code for seed() shows that if the argument is None, it
calls time.time() and uses that as the seed value:

"""
        if a is None:
            # Initialize from current time
            import time
            a = long(time.time() * 256)

        if type(a) not in (type(3), type(3L)):
            a = hash(a)

        a, x = divmod(a, 30268)
        a, y = divmod(a, 30306)
        a, z = divmod(a, 30322)
        self._seed = int(x)+1, int(y)+1, int(z)+1

        self.gauss_next = None
"""

I understand that this behavior (which DOES match the
documentation) may be inconvenient if you override the
seed() method.  You are pretty much forced to add a few
lines of code to replicate seed's documented behavior.

If the module were being rewritten from scratch, this
behavior would be factored out.  However, it has been this
way since the dawn of time and is not sufficiently painful
to warrant a change.  Or, more accurately put, changing it
would cause more discomfort than it would save (i.e. the
huge existing code base takes priority here).

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 02:39

Message:
Logged In: YES 
user_id=31435

The docs are correct.  They say that calling seed() with no 
argument is the same as calling seed(None), and that's true, 
and it's also true that both cases end up using current 
system time.  That happens because the implementation of 
seed() special-cases argument None, but the docs describe 
behavior, not implementation details.

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

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

From noreply at sourceforge.net  Sat Feb 21 03:04:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 03:06:20 2004
Subject: [ python-Bugs-901605 ] random.seed not initialized as advertised
Message-ID: <E1AuS7m-0005ad-00@sc8-sf-web1.sourceforge.net>

Bugs item #901605, was opened at 2004-02-21 00:45
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901605&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.seed not initialized as advertised

Initial Comment:
The doc for random.seed(x) says: Optional argument x
can be any hashable object. If x is omitted or None,
current system time is used; current system time is
also used to initialize the generator when the module
is first imported. 

In fact the random module calls the seed function with
x=None when a Random object is instantiated, not with
the current system time as the docs indicate.  You can
tell this by doing something like:

  import random
  class myrand(random.Random):
    def seed(x): 
       print x
       random.Random.seed(x)  
  a = myrand()

and you'll see it prints None.  Initializing with None
may be reasonable behavior, but it doesn't match the
docs.  So either the code or the doc should be updated.


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

>Comment By: Tim Peters (tim_one)
Date: 2004-02-21 03:04

Message:
Logged In: YES 
user_id=31435

Paul, please suggest exact wording that wouldn't confuse 
you.  The docs seem clear to me, and I haven't heard anyone 
else express confusion on this point.  How are you reading

"Optional argument x an be any hashable object. If x is 
omitted or None, current system time is used."

?  I don't see how it can be misread.  What did you think it 
meant?  That if you passed None, the None would get 
magically mutated in-place to become current system time?  
And that if you didn't pass anything, an argument consisting 
of current system time would be magically invented?  If so, 
that's creative <wink>.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 02:54

Message:
Logged In: YES 
user_id=31435

I don't believe we'd change this behavior -- it's intentional 
that the default seeding varies each time you run a program.  
Subclasses aren't an argument against this:  a subclass isn't 
required to mimic a base class's behavior in all respects.  If it 
were, there would be darn little point to having subclasses 
<wink>.

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

Comment By: paul rubin (phr)
Date: 2004-02-21 02:52

Message:
Logged In: YES 
user_id=72053

If that's what the docs are trying to say, they're unclear
and should be updated.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 02:46

Message:
Logged In: YES 
user_id=80475

I believe you are misreading the docs.  They describe what
Random.seed() DOES with the arguments, not HOW it is called.

The code for seed() shows that if the argument is None, it
calls time.time() and uses that as the seed value:

"""
        if a is None:
            # Initialize from current time
            import time
            a = long(time.time() * 256)

        if type(a) not in (type(3), type(3L)):
            a = hash(a)

        a, x = divmod(a, 30268)
        a, y = divmod(a, 30306)
        a, z = divmod(a, 30322)
        self._seed = int(x)+1, int(y)+1, int(z)+1

        self.gauss_next = None
"""

I understand that this behavior (which DOES match the
documentation) may be inconvenient if you override the
seed() method.  You are pretty much forced to add a few
lines of code to replicate seed's documented behavior.

If the module were being rewritten from scratch, this
behavior would be factored out.  However, it has been this
way since the dawn of time and is not sufficiently painful
to warrant a change.  Or, more accurately put, changing it
would cause more discomfort than it would save (i.e. the
huge existing code base takes priority here).

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 02:39

Message:
Logged In: YES 
user_id=31435

The docs are correct.  They say that calling seed() with no 
argument is the same as calling seed(None), and that's true, 
and it's also true that both cases end up using current 
system time.  That happens because the implementation of 
seed() special-cases argument None, but the docs describe 
behavior, not implementation details.

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

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

From noreply at sourceforge.net  Sat Feb 21 03:16:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 03:18:00 2004
Subject: [ python-Bugs-901285 ] random.randint fails for some ranges
Message-ID: <E1AuSJB-0005Zb-00@sc8-sf-web3.sourceforge.net>

Bugs item #901285, was opened at 2004-02-20 19:27
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901285&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.randint fails for some ranges

Initial Comment:
I want a random 32-bit int and do it the obvious way:

lowest, highest = int(-2**31), int(2**31-1)
r = random.randint(lowest, highest)

random.randint throws an exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/random.py", line 349, in randint
    return self.randrange(a, b+1)
  File "/usr/lib/python2.2/random.py", line 328, in
randrange
    raise ValueError, "empty range for randrange()"
ValueError: empty range for randrange()


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

>Comment By: paul rubin (phr)
Date: 2004-02-21 08:16

Message:
Logged In: YES 
user_id=72053

It says "; current system time is also used to initialize
the generator when the module is first imported. "  That
sugests that the module is passing the current time to the
generator, rather than that the generator is initializing
itself with the current time.

Proposed new wording: ".  When a new generator is
instantiated, its inititialization method calls the seed
operation with a parameter of None.  The seed method then
uses the current time to initialize the generator as
described above.  If you subclass Random, your seed
operation can use some different method to create a default
seed on being initialized with None."

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

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

From noreply at sourceforge.net  Sat Feb 21 03:17:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 03:18:49 2004
Subject: [ python-Bugs-901285 ] random.randint fails for some ranges
Message-ID: <E1AuSJu-0005sl-00@sc8-sf-web1.sourceforge.net>

Bugs item #901285, was opened at 2004-02-20 19:27
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901285&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.randint fails for some ranges

Initial Comment:
I want a random 32-bit int and do it the obvious way:

lowest, highest = int(-2**31), int(2**31-1)
r = random.randint(lowest, highest)

random.randint throws an exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/random.py", line 349, in randint
    return self.randrange(a, b+1)
  File "/usr/lib/python2.2/random.py", line 328, in
randrange
    raise ValueError, "empty range for randrange()"
ValueError: empty range for randrange()


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

>Comment By: paul rubin (phr)
Date: 2004-02-21 08:17

Message:
Logged In: YES 
user_id=72053

Oops, ignore previous comment, it was added to the wrong
bug.  Sorry.

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

Comment By: paul rubin (phr)
Date: 2004-02-21 08:16

Message:
Logged In: YES 
user_id=72053

It says "; current system time is also used to initialize
the generator when the module is first imported. "  That
sugests that the module is passing the current time to the
generator, rather than that the generator is initializing
itself with the current time.

Proposed new wording: ".  When a new generator is
instantiated, its inititialization method calls the seed
operation with a parameter of None.  The seed method then
uses the current time to initialize the generator as
described above.  If you subclass Random, your seed
operation can use some different method to create a default
seed on being initialized with None."

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

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

From noreply at sourceforge.net  Sat Feb 21 03:17:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 03:19:21 2004
Subject: [ python-Bugs-901285 ] random.randint fails for some ranges
Message-ID: <E1AuSKQ-0000Eg-00@sc8-sf-web4.sourceforge.net>

Bugs item #901285, was opened at 2004-02-20 14:27
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901285&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
>Resolution: Wont Fix
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.randint fails for some ranges

Initial Comment:
I want a random 32-bit int and do it the obvious way:

lowest, highest = int(-2**31), int(2**31-1)
r = random.randint(lowest, highest)

random.randint throws an exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/random.py", line 349, in randint
    return self.randrange(a, b+1)
  File "/usr/lib/python2.2/random.py", line 328, in
randrange
    raise ValueError, "empty range for randrange()"
ValueError: empty range for randrange()


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 03:17

Message:
Logged In: YES 
user_id=80475

This has been fixed for Py2.3.3 and 2.4 as a result of the
automatic conversion between ints and longs.

In 2.2, it is still possible, but the call to int() inside
random.randrange() would be have to be changed to math.floor() 
which can handle the full range.  As the comments indicate,
this was not worth a performance hit.

As a workaround, generate two 16 bit integers and then join
them with (a << 16) | b.  This ought to work for practical
purposes; however, the underlying generator may not be
strong enough to make this a theoretically reliable
transform (i.e. it may dramatically shorten the period of
the composite generator).

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

Comment By: paul rubin (phr)
Date: 2004-02-21 03:17

Message:
Logged In: YES 
user_id=72053

Oops, ignore previous comment, it was added to the wrong
bug.  Sorry.

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

Comment By: paul rubin (phr)
Date: 2004-02-21 03:16

Message:
Logged In: YES 
user_id=72053

It says "; current system time is also used to initialize
the generator when the module is first imported. "  That
sugests that the module is passing the current time to the
generator, rather than that the generator is initializing
itself with the current time.

Proposed new wording: ".  When a new generator is
instantiated, its inititialization method calls the seed
operation with a parameter of None.  The seed method then
uses the current time to initialize the generator as
described above.  If you subclass Random, your seed
operation can use some different method to create a default
seed on being initialized with None."

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

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

From noreply at sourceforge.net  Sat Feb 21 03:18:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 03:19:56 2004
Subject: [ python-Bugs-901285 ] random.randint fails for some ranges
Message-ID: <E1AuSKz-0000Fm-00@sc8-sf-web4.sourceforge.net>

Bugs item #901285, was opened at 2004-02-20 14:27
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901285&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.randint fails for some ranges

Initial Comment:
I want a random 32-bit int and do it the obvious way:

lowest, highest = int(-2**31), int(2**31-1)
r = random.randint(lowest, highest)

random.randint throws an exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/random.py", line 349, in randint
    return self.randrange(a, b+1)
  File "/usr/lib/python2.2/random.py", line 328, in
randrange
    raise ValueError, "empty range for randrange()"
ValueError: empty range for randrange()


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 03:17

Message:
Logged In: YES 
user_id=80475

This has been fixed for Py2.3.3 and 2.4 as a result of the
automatic conversion between ints and longs.

In 2.2, it is still possible, but the call to int() inside
random.randrange() would be have to be changed to math.floor() 
which can handle the full range.  As the comments indicate,
this was not worth a performance hit.

As a workaround, generate two 16 bit integers and then join
them with (a << 16) | b.  This ought to work for practical
purposes; however, the underlying generator may not be
strong enough to make this a theoretically reliable
transform (i.e. it may dramatically shorten the period of
the composite generator).

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

Comment By: paul rubin (phr)
Date: 2004-02-21 03:17

Message:
Logged In: YES 
user_id=72053

Oops, ignore previous comment, it was added to the wrong
bug.  Sorry.

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

Comment By: paul rubin (phr)
Date: 2004-02-21 03:16

Message:
Logged In: YES 
user_id=72053

It says "; current system time is also used to initialize
the generator when the module is first imported. "  That
sugests that the module is passing the current time to the
generator, rather than that the generator is initializing
itself with the current time.

Proposed new wording: ".  When a new generator is
instantiated, its inititialization method calls the seed
operation with a parameter of None.  The seed method then
uses the current time to initialize the generator as
described above.  If you subclass Random, your seed
operation can use some different method to create a default
seed on being initialized with None."

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

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

From noreply at sourceforge.net  Sat Feb 21 03:18:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 03:20:10 2004
Subject: [ python-Bugs-901605 ] random.seed not initialized as advertised
Message-ID: <E1AuSLD-0005vm-00@sc8-sf-web1.sourceforge.net>

Bugs item #901605, was opened at 2004-02-21 05:45
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901605&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.seed not initialized as advertised

Initial Comment:
The doc for random.seed(x) says: Optional argument x
can be any hashable object. If x is omitted or None,
current system time is used; current system time is
also used to initialize the generator when the module
is first imported. 

In fact the random module calls the seed function with
x=None when a Random object is instantiated, not with
the current system time as the docs indicate.  You can
tell this by doing something like:

  import random
  class myrand(random.Random):
    def seed(x): 
       print x
       random.Random.seed(x)  
  a = myrand()

and you'll see it prints None.  Initializing with None
may be reasonable behavior, but it doesn't match the
docs.  So either the code or the doc should be updated.


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

>Comment By: paul rubin (phr)
Date: 2004-02-21 08:18

Message:
Logged In: YES 
user_id=72053

It says "; current system time is also used to initialize
the generator when the module is first imported. "  That
sugests (but doesn't state) that the module is passing the
current time to the generator, rather than that the
generator is initializing
itself with the current time.
 
Proposed new wording: ".  When a new generator is
instantiated, its inititialization method calls the seed
operation with a parameter of None.  The seed method then
uses the current time to initialize the generator as
described above.  If you subclass Random, your seed
operation can use some different method to create a default
seed on being initialized with None."


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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 08:04

Message:
Logged In: YES 
user_id=31435

Paul, please suggest exact wording that wouldn't confuse 
you.  The docs seem clear to me, and I haven't heard anyone 
else express confusion on this point.  How are you reading

"Optional argument x an be any hashable object. If x is 
omitted or None, current system time is used."

?  I don't see how it can be misread.  What did you think it 
meant?  That if you passed None, the None would get 
magically mutated in-place to become current system time?  
And that if you didn't pass anything, an argument consisting 
of current system time would be magically invented?  If so, 
that's creative <wink>.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 07:54

Message:
Logged In: YES 
user_id=31435

I don't believe we'd change this behavior -- it's intentional 
that the default seeding varies each time you run a program.  
Subclasses aren't an argument against this:  a subclass isn't 
required to mimic a base class's behavior in all respects.  If it 
were, there would be darn little point to having subclasses 
<wink>.

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

Comment By: paul rubin (phr)
Date: 2004-02-21 07:52

Message:
Logged In: YES 
user_id=72053

If that's what the docs are trying to say, they're unclear
and should be updated.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 07:46

Message:
Logged In: YES 
user_id=80475

I believe you are misreading the docs.  They describe what
Random.seed() DOES with the arguments, not HOW it is called.

The code for seed() shows that if the argument is None, it
calls time.time() and uses that as the seed value:

"""
        if a is None:
            # Initialize from current time
            import time
            a = long(time.time() * 256)

        if type(a) not in (type(3), type(3L)):
            a = hash(a)

        a, x = divmod(a, 30268)
        a, y = divmod(a, 30306)
        a, z = divmod(a, 30322)
        self._seed = int(x)+1, int(y)+1, int(z)+1

        self.gauss_next = None
"""

I understand that this behavior (which DOES match the
documentation) may be inconvenient if you override the
seed() method.  You are pretty much forced to add a few
lines of code to replicate seed's documented behavior.

If the module were being rewritten from scratch, this
behavior would be factored out.  However, it has been this
way since the dawn of time and is not sufficiently painful
to warrant a change.  Or, more accurately put, changing it
would cause more discomfort than it would save (i.e. the
huge existing code base takes priority here).

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 07:39

Message:
Logged In: YES 
user_id=31435

The docs are correct.  They say that calling seed() with no 
argument is the same as calling seed(None), and that's true, 
and it's also true that both cases end up using current 
system time.  That happens because the implementation of 
seed() special-cases argument None, but the docs describe 
behavior, not implementation details.

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

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

From noreply at sourceforge.net  Sat Feb 21 03:19:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 03:21:06 2004
Subject: [ python-Bugs-900071 ] optparse: usage issues
Message-ID: <E1AuSM0-0000HP-00@sc8-sf-web4.sourceforge.net>

Bugs item #900071, was opened at 2004-02-19 02:14
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900071&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
>Assigned to: Greg Ward (gward)
Summary: optparse: usage issues

Initial Comment:
current documentation states that 

usage = "usage: %prog [options] arg1 arg2"
parser = OptionParser(usage=usage)

would yield

usage: <yourscript> [options] arg1 arg2

however, using python 2.3.2

usage = "Usage: %prog [options] file"

yields:

usage: Usage <yourscript> [options] file"


IMO, it should be possible to replace the whole thing
(think i18n)

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

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

From noreply at sourceforge.net  Sat Feb 21 03:20:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 03:22:25 2004
Subject: [ python-Bugs-901330 ] logging handlers can close without flush
Message-ID: <E1AuSNJ-0000JX-00@sc8-sf-web4.sourceforge.net>

Bugs item #901330, was opened at 2004-02-20 15:14
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901330&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging handlers can close without flush

Initial Comment:
logging.Handler().close() does not call flush().  Some 
derived handlers override this and call flush themselves; 
some do not.  I'm not certain which streams are buffered 
under the hood, but I think it would be fine to call flush in 
all cases.  In particular, I think BufferingHandler should 
always flush, and FileHandler probably should too.

Note that just adding it to Handler().close() would not 
work with the current CVS version, as the derived class 
may call the parent close (to clean up _handlers) after 
closing (and making unflushable) the stream.


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

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

From noreply at sourceforge.net  Sat Feb 21 03:35:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 03:37:40 2004
Subject: [ python-Bugs-901605 ] random.seed not initialized as advertised
Message-ID: <E1AuSc8-0006Rb-00@sc8-sf-web1.sourceforge.net>

Bugs item #901605, was opened at 2004-02-21 00:45
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901605&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.seed not initialized as advertised

Initial Comment:
The doc for random.seed(x) says: Optional argument x
can be any hashable object. If x is omitted or None,
current system time is used; current system time is
also used to initialize the generator when the module
is first imported. 

In fact the random module calls the seed function with
x=None when a Random object is instantiated, not with
the current system time as the docs indicate.  You can
tell this by doing something like:

  import random
  class myrand(random.Random):
    def seed(x): 
       print x
       random.Random.seed(x)  
  a = myrand()

and you'll see it prints None.  Initializing with None
may be reasonable behavior, but it doesn't match the
docs.  So either the code or the doc should be updated.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 03:35

Message:
Logged In: YES 
user_id=80475

We should not make this change for several reasons:

* you're describing the behavior of the caller, not the
callee.  the quoted docs are for the seed() method which
appropriately describes what it does with the arguments, not
how it  
is called by Random.__init__()

* The current wording is simple, direct, and has not been
misinterpreted by most people.  Expanding it to the more
convoluted wording would, IMO, make it less clear to most
people.  In the docs, if you explain something to death,
they become harder to understand.  Details are good, but
going on to describe how you would subclass and override for
one particular effect is a distracting digression.

* Having a method describe how it is called is a recipe for
the docs not getting updated in the future.  If I change the
instantiation behavior without changing seed, I would not
normally re-examine the doc string for seed().



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

Comment By: paul rubin (phr)
Date: 2004-02-21 03:18

Message:
Logged In: YES 
user_id=72053

It says "; current system time is also used to initialize
the generator when the module is first imported. "  That
sugests (but doesn't state) that the module is passing the
current time to the generator, rather than that the
generator is initializing
itself with the current time.
 
Proposed new wording: ".  When a new generator is
instantiated, its inititialization method calls the seed
operation with a parameter of None.  The seed method then
uses the current time to initialize the generator as
described above.  If you subclass Random, your seed
operation can use some different method to create a default
seed on being initialized with None."


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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 03:04

Message:
Logged In: YES 
user_id=31435

Paul, please suggest exact wording that wouldn't confuse 
you.  The docs seem clear to me, and I haven't heard anyone 
else express confusion on this point.  How are you reading

"Optional argument x an be any hashable object. If x is 
omitted or None, current system time is used."

?  I don't see how it can be misread.  What did you think it 
meant?  That if you passed None, the None would get 
magically mutated in-place to become current system time?  
And that if you didn't pass anything, an argument consisting 
of current system time would be magically invented?  If so, 
that's creative <wink>.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 02:54

Message:
Logged In: YES 
user_id=31435

I don't believe we'd change this behavior -- it's intentional 
that the default seeding varies each time you run a program.  
Subclasses aren't an argument against this:  a subclass isn't 
required to mimic a base class's behavior in all respects.  If it 
were, there would be darn little point to having subclasses 
<wink>.

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

Comment By: paul rubin (phr)
Date: 2004-02-21 02:52

Message:
Logged In: YES 
user_id=72053

If that's what the docs are trying to say, they're unclear
and should be updated.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 02:46

Message:
Logged In: YES 
user_id=80475

I believe you are misreading the docs.  They describe what
Random.seed() DOES with the arguments, not HOW it is called.

The code for seed() shows that if the argument is None, it
calls time.time() and uses that as the seed value:

"""
        if a is None:
            # Initialize from current time
            import time
            a = long(time.time() * 256)

        if type(a) not in (type(3), type(3L)):
            a = hash(a)

        a, x = divmod(a, 30268)
        a, y = divmod(a, 30306)
        a, z = divmod(a, 30322)
        self._seed = int(x)+1, int(y)+1, int(z)+1

        self.gauss_next = None
"""

I understand that this behavior (which DOES match the
documentation) may be inconvenient if you override the
seed() method.  You are pretty much forced to add a few
lines of code to replicate seed's documented behavior.

If the module were being rewritten from scratch, this
behavior would be factored out.  However, it has been this
way since the dawn of time and is not sufficiently painful
to warrant a change.  Or, more accurately put, changing it
would cause more discomfort than it would save (i.e. the
huge existing code base takes priority here).

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 02:39

Message:
Logged In: YES 
user_id=31435

The docs are correct.  They say that calling seed() with no 
argument is the same as calling seed(None), and that's true, 
and it's also true that both cases end up using current 
system time.  That happens because the implementation of 
seed() special-cases argument None, but the docs describe 
behavior, not implementation details.

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

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

From noreply at sourceforge.net  Sat Feb 21 03:36:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 03:38:36 2004
Subject: [ python-Bugs-900626 ] add logging.shutdown() to python logging
	module example code
Message-ID: <E1AuScy-0006T4-00@sc8-sf-web1.sourceforge.net>

Bugs item #900626, was opened at 2004-02-19 15:45
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900626&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Manuel Schulte (manuel)
>Assigned to: Vinay Sajip (vsajip)
Summary: add logging.shutdown() to python logging module example code

Initial Comment:
Hi There,

I was trying to get logging with the logging module
working using code from the example provided in section
6.28.8.1 in the documentation.  My log file was empty
after program execution completed.  I ended up adding
'logging.shutdown()' to the end of the example code to
finally see the results in the file ('hdlr.close()'
works as well).

cheers,
manuel






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

Comment By: Jim Jewett (jimjjewett)
Date: 2004-02-20 15:26

Message:
Logged In: YES 
user_id=764593

Correct, but ...

With current code, you want to be sure that you don't call 
shutdown more than once.

With CVS code, you will no longer need to call shutdown 
manually.  So the doco change won't be needed either.

If you just want to hurry the results along, you can call 
hdlr.flush(), which still leaves the handler open for further use.


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

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

From noreply at sourceforge.net  Sat Feb 21 03:43:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 03:45:48 2004
Subject: [ python-Bugs-884841 ] Incorrect ZeroDivisionError message with
	__future__ division
Message-ID: <E1AuSju-0007j8-00@sc8-sf-web2.sourceforge.net>

Bugs item #884841, was opened at 2004-01-26 11:10
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=884841&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Gerrit Holl (gerrit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect ZeroDivisionError message with __future__ division

Initial Comment:
>>> 1/0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ZeroDivisionError: integer division or modulo by zero
>>> from __future__ import division
>>> 1/0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ZeroDivisionError: float division

The latter is incorrect, or at least confusing, because
we aren't dividing floats, we're dividing integers.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 03:43

Message:
Logged In: YES 
user_id=80475

This may be a matter of perspective.  The whole point of
true division is to treat integer division arguments as
floating point.

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

Comment By: Gerrit Holl (gerrit)
Date: 2004-01-26 11:19

Message:
Logged In: YES 
user_id=13298

Hmm, OK, my misunderstanding then. It is indeed confusing ;-)

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

Comment By: Tim Peters (tim_one)
Date: 2004-01-26 11:14

Message:
Logged In: YES 
user_id=31435

But with __future__ division, int/int *is* float division.  
int//int (two slashes) is integer division then.

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

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

From noreply at sourceforge.net  Sat Feb 21 03:58:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 04:00:04 2004
Subject: [ python-Bugs-901605 ] random.seed not initialized as advertised
Message-ID: <E1AuSxb-00073u-00@sc8-sf-web1.sourceforge.net>

Bugs item #901605, was opened at 2004-02-21 05:45
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901605&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: random.seed not initialized as advertised

Initial Comment:
The doc for random.seed(x) says: Optional argument x
can be any hashable object. If x is omitted or None,
current system time is used; current system time is
also used to initialize the generator when the module
is first imported. 

In fact the random module calls the seed function with
x=None when a Random object is instantiated, not with
the current system time as the docs indicate.  You can
tell this by doing something like:

  import random
  class myrand(random.Random):
    def seed(x): 
       print x
       random.Random.seed(x)  
  a = myrand()

and you'll see it prints None.  Initializing with None
may be reasonable behavior, but it doesn't match the
docs.  So either the code or the doc should be updated.


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

>Comment By: paul rubin (phr)
Date: 2004-02-21 08:58

Message:
Logged In: YES 
user_id=72053

1. When it says how the generator is initialized when the
module is first loaded, that's describing the caller.  If
you're saying behavior of the caller should be documented
elsewhere than on the docs of a particular method, that's
fine; but remember that this doc supposedly describes the
Random class, and part of the behavior of that class is that
its initializer calls self.seed with an arg of None.  That's
undocumented behavior, and undocumented behavior is never a
good thing.  So it should be documented one way or another,
maybe as a description for the Random.__init__ method.

2. I don't know how you can say that most people haven't
misinterpreted the current wording.  The only way anyone
will find out if they misinterpreted it is if they try to
subclass Random on the basis of the doc (rather than on
additional knowledge), and how many people go around doing
that?  I'm the first one that I know of, and I
misinterpreted the doc.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 08:35

Message:
Logged In: YES 
user_id=80475

We should not make this change for several reasons:

* you're describing the behavior of the caller, not the
callee.  the quoted docs are for the seed() method which
appropriately describes what it does with the arguments, not
how it  
is called by Random.__init__()

* The current wording is simple, direct, and has not been
misinterpreted by most people.  Expanding it to the more
convoluted wording would, IMO, make it less clear to most
people.  In the docs, if you explain something to death,
they become harder to understand.  Details are good, but
going on to describe how you would subclass and override for
one particular effect is a distracting digression.

* Having a method describe how it is called is a recipe for
the docs not getting updated in the future.  If I change the
instantiation behavior without changing seed, I would not
normally re-examine the doc string for seed().



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

Comment By: paul rubin (phr)
Date: 2004-02-21 08:18

Message:
Logged In: YES 
user_id=72053

It says "; current system time is also used to initialize
the generator when the module is first imported. "  That
sugests (but doesn't state) that the module is passing the
current time to the generator, rather than that the
generator is initializing
itself with the current time.
 
Proposed new wording: ".  When a new generator is
instantiated, its inititialization method calls the seed
operation with a parameter of None.  The seed method then
uses the current time to initialize the generator as
described above.  If you subclass Random, your seed
operation can use some different method to create a default
seed on being initialized with None."


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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 08:04

Message:
Logged In: YES 
user_id=31435

Paul, please suggest exact wording that wouldn't confuse 
you.  The docs seem clear to me, and I haven't heard anyone 
else express confusion on this point.  How are you reading

"Optional argument x an be any hashable object. If x is 
omitted or None, current system time is used."

?  I don't see how it can be misread.  What did you think it 
meant?  That if you passed None, the None would get 
magically mutated in-place to become current system time?  
And that if you didn't pass anything, an argument consisting 
of current system time would be magically invented?  If so, 
that's creative <wink>.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 07:54

Message:
Logged In: YES 
user_id=31435

I don't believe we'd change this behavior -- it's intentional 
that the default seeding varies each time you run a program.  
Subclasses aren't an argument against this:  a subclass isn't 
required to mimic a base class's behavior in all respects.  If it 
were, there would be darn little point to having subclasses 
<wink>.

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

Comment By: paul rubin (phr)
Date: 2004-02-21 07:52

Message:
Logged In: YES 
user_id=72053

If that's what the docs are trying to say, they're unclear
and should be updated.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 07:46

Message:
Logged In: YES 
user_id=80475

I believe you are misreading the docs.  They describe what
Random.seed() DOES with the arguments, not HOW it is called.

The code for seed() shows that if the argument is None, it
calls time.time() and uses that as the seed value:

"""
        if a is None:
            # Initialize from current time
            import time
            a = long(time.time() * 256)

        if type(a) not in (type(3), type(3L)):
            a = hash(a)

        a, x = divmod(a, 30268)
        a, y = divmod(a, 30306)
        a, z = divmod(a, 30322)
        self._seed = int(x)+1, int(y)+1, int(z)+1

        self.gauss_next = None
"""

I understand that this behavior (which DOES match the
documentation) may be inconvenient if you override the
seed() method.  You are pretty much forced to add a few
lines of code to replicate seed's documented behavior.

If the module were being rewritten from scratch, this
behavior would be factored out.  However, it has been this
way since the dawn of time and is not sufficiently painful
to warrant a change.  Or, more accurately put, changing it
would cause more discomfort than it would save (i.e. the
huge existing code base takes priority here).

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-21 07:39

Message:
Logged In: YES 
user_id=31435

The docs are correct.  They say that calling seed() with no 
argument is the same as calling seed(None), and that's true, 
and it's also true that both cases end up using current 
system time.  That happens because the implementation of 
seed() special-cases argument None, but the docs describe 
behavior, not implementation details.

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

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

From noreply at sourceforge.net  Sat Feb 21 04:22:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 04:24:23 2004
Subject: [ python-Bugs-901654 ] split method documentation can be improved
Message-ID: <E1AuTLF-0007Lq-00@sc8-sf-web3.sourceforge.net>

Bugs item #901654, was opened at 2004-02-21 10:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901654&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Raymond Hettinger (rhettinger)
Summary: split method documentation can be improved

Initial Comment:
If you compare the documentation for the string.split
function and the split method on strings, you'll find
the former much clearer in the description of what
happens with a None separator argument.  The doc
strings of both are like the method, not terribly precise.

It may be worth it to compare other string methods /
string module functions.

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

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

From noreply at sourceforge.net  Sat Feb 21 10:04:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 10:05:53 2004
Subject: [ python-Bugs-901727 ] extra_path kwarg to setup() undocumented
Message-ID: <E1AuYfn-00031f-00@sc8-sf-web1.sourceforge.net>

Bugs item #901727, was opened at 2004-02-21 10:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901727&group_id=5470

Category: Distutils
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: extra_path kwarg to setup() undocumented

Initial Comment:
I can't find documentation for extra_path anywhere.. but this is the 
documentation I found by searching google ( http://
mail.python.org/pipermail/distutils-sig/2000-March/000803.html ), 
from an old USAGE.txt that sits in the CVS attic now:

extra_path:
     information about extra intervening directories to put between
     'install_lib' and 'install_sitelib', along with a .pth file to
     ensure that those directories wind up in sys.path.  Can be a 1- 
or
     2-tuple, or a comma-delimited string with 1 or 2 parts.  The
     1-element case is simpler: the .pth file and directory have the 
same
    name (except for ".pth").  Eg. if extra_path is "foo" or ("foo",),
     then Distutils sets 'install_site_lib' to 'install_lib' +
     "site-packages/foo", and puts foo.path in the "site-packages"
     directory; it contains just "foo".  The 2-element case allows the
     .pth file and intervening directories to be named differently; 
eg.
    if 'extra_path' is ("foo","foo/bar/baz") (or "foo,foo/bar/baz"),
     then Distutils will set 'install_site_lib' to 'install_lib' +
     "site-packages/foo/bar/baz", and put "foo.pth" containing
     "foo/bar/baz" in the "site-packages" directory.

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

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

From noreply at sourceforge.net  Sat Feb 21 10:04:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 10:06:13 2004
Subject: [ python-Bugs-901727 ] extra_path kwarg to setup() undocumented
Message-ID: <E1AuYg5-0006oM-00@sc8-sf-web4.sourceforge.net>

Bugs item #901727, was opened at 2004-02-21 10:04
Message generated for change (Settings changed) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901727&group_id=5470

Category: Distutils
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
>Assigned to: Thomas Heller (theller)
Summary: extra_path kwarg to setup() undocumented

Initial Comment:
I can't find documentation for extra_path anywhere.. but this is the 
documentation I found by searching google ( http://
mail.python.org/pipermail/distutils-sig/2000-March/000803.html ), 
from an old USAGE.txt that sits in the CVS attic now:

extra_path:
     information about extra intervening directories to put between
     'install_lib' and 'install_sitelib', along with a .pth file to
     ensure that those directories wind up in sys.path.  Can be a 1- 
or
     2-tuple, or a comma-delimited string with 1 or 2 parts.  The
     1-element case is simpler: the .pth file and directory have the 
same
    name (except for ".pth").  Eg. if extra_path is "foo" or ("foo",),
     then Distutils sets 'install_site_lib' to 'install_lib' +
     "site-packages/foo", and puts foo.path in the "site-packages"
     directory; it contains just "foo".  The 2-element case allows the
     .pth file and intervening directories to be named differently; 
eg.
    if 'extra_path' is ("foo","foo/bar/baz") (or "foo,foo/bar/baz"),
     then Distutils will set 'install_site_lib' to 'install_lib' +
     "site-packages/foo/bar/baz", and put "foo.pth" containing
     "foo/bar/baz" in the "site-packages" directory.

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

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

From noreply at sourceforge.net  Sat Feb 21 11:30:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 11:32:36 2004
Subject: [ python-Bugs-897872 ] Unknown color name on HP-UX
Message-ID: <E1Aua1f-0005g8-00@sc8-sf-web3.sourceforge.net>

Bugs item #897872, was opened at 2004-02-16 08:37
Message generated for change (Comment added) made by rptownsend
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897872&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unknown color name on HP-UX

Initial Comment:
When I click on a node in the class browser tree widget, 
I get: 

TclError: unknown color name "darkblue".

This is coming from line 253 in TreeWidget.py where the 
background color is hard-coded as "darkblue".

On HP-UX 11.11 there is no entry for "darkblue" in 
rgb.txt.



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

>Comment By: Richard Townsend (rptownsend)
Date: 2004-02-21 16:30

Message:
Logged In: YES 
user_id=200117

One of my collegues tried adding an entry to rgb.txt on
HP-UX and running the rgb util, but he couldn't get X to
recognise the new color.

Looking at the rgb.txt files on HP-UX and Linux (SuSE 8.2)
there  are many differences, not just color names that are
missing, but definitions which are different. 

I wrote a little script to compare the files. I have
attached its output.

However, the definition for 'darkblue' on Linux is identical
to 'blue4' on both Linux and HP-UX (0, 0, 139). 

Perhaps the simplest thing would be for IDLE to use 'blue4' ?



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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-19 00:48

Message:
Logged In: YES 
user_id=593130

Given the apparent absence of problems on others systems, 
perhaps the absence of a 'darkblue' entry is a bug that should 
be reported to HP.  Do you know anything of the specs for 
rgb.txt?  And can you add such an entry to fix the problem?

If you are sure the absence if legit, what color can be 
depended on if 'darkblue' does not work?

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

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

From noreply at sourceforge.net  Sat Feb 21 12:09:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 12:11:09 2004
Subject: [ python-Bugs-900949 ] plat-mac/videoreader.py not working on OS X
Message-ID: <E1Auacm-0008CV-00@sc8-sf-web1.sourceforge.net>

Bugs item #900949, was opened at 2004-02-20 08:52
Message generated for change (Comment added) made by dinu_gherman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900949&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Dinu C. Gherman (dinu_gherman)
Assigned to: Jack Jansen (jackjansen)
Summary: plat-mac/videoreader.py not working on OS X

Initial Comment:
plat-mac/videoreader.py uses modules like "img" which 
used to be in Mac OS 9 builds, but are no longer in OS X 
builds. I suggest replacing the pieces with code writing 
images using PIL, if available.

The critical new pieces (whithout checks for PIL) in methods 
ReadVideo/_getpixmapcontent are:

#-----------------------------
from PIL import Image
...
# convert from ARGB to RGBA (faster/better anyone?)
data = []
for i in xrange(0, width*height*4, 4):
        a, r, g, b = rv[i:i+4]
        data.append(r + g + b + a)
data = ''.join(data)
# save image using PIL
img = Image.fromstring("RGBA", (width, height), data)
img.save(<<some filename>>+".jpg", "JPEG")
#-----------------------------

See also my posting on the pythonmac list and its attached 
script:

http://mail.python.org/pipermail/pythonmac-sig/2004-
February/010282.html

or see the attached file (which does not do exactly the same 
as videoreader.py!)...

Dinu

PS: This is on Py 2.3.3 on Mac OS X 10.2.8...

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

>Comment By: Dinu C. Gherman (dinu_gherman)
Date: 2004-02-21 17:09

Message:
Logged In: YES 
user_id=12190

Also note that a using ''.join() as in the function I'm using below is 
much faster than repeated string concatenation as in 
videoreader.py:

def convertPixmapToARGB(pixmap, width, height):
    rowbytes = Qdoffs.GetPixRowBytes(pixmap)
    start = 0
    rv = []
    getBytes = Qdoffs.GetPixMapBytes
    for i in xrange(height):
        nextline = getBytes(pixmap, start, width*4)
        start = start + rowbytes
        rv.append(nextline)
    rv = ''.join(rv)
    return rv

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

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

From noreply at sourceforge.net  Sat Feb 21 15:01:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 15:03:48 2004
Subject: [ python-Bugs-897625 ] time.strftime crashes python
Message-ID: <E1AudK1-0006nx-00@sc8-sf-web1.sourceforge.net>

Bugs item #897625, was opened at 2004-02-15 13:33
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897625&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Tom Lynn (tlynn)
Assigned to: Brett Cannon (bcannon)
Summary: time.strftime crashes python

Initial Comment:
On Win2k:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Python dumps core.  Is that (ever) expected behaviour?

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

>Comment By: Brett Cannon (bcannon)
Date: 2004-02-21 12:01

Message:
Logged In: YES 
user_id=357491

OK, have a solution coded up, just waiting to hear from Tim on whether a 
change to datetime is okay with him.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 13:59

Message:
Logged In: YES 
user_id=357491

Should be able to deal with this cleanly by modifying gettmarg() to do 
some sanity checks on the values before returning and letting 
time_strftime() at the struct tm that gettmarg() created.

First have to check the ISO C standard, though, to make sure I don't 
overstep my bounds on the sanity checks (or I could just follow our own 
specs, but that would be too easy  =).

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 12:36

Message:
Logged In: YES 
user_id=304464

On WinXP Home does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\xfcI\xc1w\xf8I\xc1w\xf4I\xc1w\xf0I\xc1w\xecI\xc1w\xe8I\xc1w\xe4I\xc1w\xdcI\xc1w\xd4I\xc1w\xccI\xc1w\xc0I\xc1w\xb4I\xc1w\xacI\xc1w\xa0I\xc1w\x9cI\xc1w\x98I\xc1w\x94I\xc1w\x90I\xc1w\x8cI\xc1w\x88I\xc1w\x84I\xc1w\x80I\xc1w|I\xc1wxI\xc1wtI\xc1wpI\xc1whI\xc1w\I\xc1wTI\xc1wLI\xc1w\x8cI\xc1wDI\xc1w<I\xc1w4I\xc1w(I\xc1wI\xc1w\x14I\xc1w\x08I\xc1w\x04I\xc1w'

ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit
(Intel)] on win32


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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 12:34

Message:
Logged In: YES 
user_id=304464

On my linux system does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\x0e'

Python 2.3.3c1 (#2, Dec  6 2003, 16:44:56)
[GCC 3.3.3 20031203 (prerelease) (Debian)] on linux2

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 12:32

Message:
Logged In: YES 
user_id=304464

Also, please have a look at:
https://sourceforge.net/tracker/index.php?func=detail&aid=898253&group_id=5470&atid=105470

at the same time.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-15 17:23

Message:
Logged In: YES 
user_id=31435

I assume this is specific to Python on Windows using 
Microsoft's C, since this workalike plain C program also dies 
with a memory error while in the bowels of MS's strftime():

#include <stdio.h>
#include <time.h>

void main() {
    struct tm t;
    char buf[256];
    size_t i;

    t.tm_year = 1900 - 1900;
    t.tm_mon = 1 - 1;
    t.tm_mday = 1;
    t.tm_hour = 13;
    t.tm_min = 0;
    t.tm_sec = 0;
    t.tm_wday = -3;
    t.tm_yday = 0;
    t.tm_isdst = -1;

    printf("calling strftime\n");
    i = strftime(buf, sizeof(buf), "%a", &t);
    printf("i: %d\n", i);
}

The problem is the negative value for tm_wday.  MS strftime 
isn't defensive, and uses the negative tm_wday to index into 
nonsense memory.  Ironically, if C had defined the % operator 
in the sane way (meaning Python's way <wink>), a negative 
tm_wday wouldn't have survived for the C library function to 
see.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-15 15:41

Message:
Logged In: YES 
user_id=80475

It is expected.  Well, now that I've confirmed it on Py2.3.3
and Py2.4, yes ;-) 

Is it desirable?  Heck no.

Brett, can you take a look at this?

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

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

From noreply at sourceforge.net  Sat Feb 21 17:19:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 17:21:00 2004
Subject: [ python-Bugs-901330 ] logging handlers can close without flush
Message-ID: <E1AufSo-0003Jm-00@sc8-sf-web1.sourceforge.net>

Bugs item #901330, was opened at 2004-02-20 20:14
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901330&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Vinay Sajip (vsajip)
Summary: logging handlers can close without flush

Initial Comment:
logging.Handler().close() does not call flush().  Some 
derived handlers override this and call flush themselves; 
some do not.  I'm not certain which streams are buffered 
under the hood, but I think it would be fine to call flush in 
all cases.  In particular, I think BufferingHandler should 
always flush, and FileHandler probably should too.

Note that just adding it to Handler().close() would not 
work with the current CVS version, as the derived class 
may call the parent close (to clean up _handlers) after 
closing (and making unflushable) the stream.


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

>Comment By: Vinay Sajip (vsajip)
Date: 2004-02-21 22:19

Message:
Logged In: YES 
user_id=308438

Just checked in fixes into CVS.

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

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

From noreply at sourceforge.net  Sat Feb 21 17:21:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 17:23:03 2004
Subject: [ python-Bugs-900626 ] add logging.shutdown() to python logging
	module example code
Message-ID: <E1AufUq-0003O9-00@sc8-sf-web1.sourceforge.net>

Bugs item #900626, was opened at 2004-02-19 20:45
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900626&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Manuel Schulte (manuel)
Assigned to: Vinay Sajip (vsajip)
Summary: add logging.shutdown() to python logging module example code

Initial Comment:
Hi There,

I was trying to get logging with the logging module
working using code from the example provided in section
6.28.8.1 in the documentation.  My log file was empty
after program execution completed.  I ended up adding
'logging.shutdown()' to the end of the example code to
finally see the results in the file ('hdlr.close()'
works as well).

cheers,
manuel






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

>Comment By: Vinay Sajip (vsajip)
Date: 2004-02-21 22:21

Message:
Logged In: YES 
user_id=308438

Recent CVS changes will mean this bug is fixed, and as noted 
by Jim Jewett, documentation changes are not needed.

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

Comment By: Jim Jewett (jimjjewett)
Date: 2004-02-20 20:26

Message:
Logged In: YES 
user_id=764593

Correct, but ...

With current code, you want to be sure that you don't call 
shutdown more than once.

With CVS code, you will no longer need to call shutdown 
manually.  So the doco change won't be needed either.

If you just want to hurry the results along, you can call 
hdlr.flush(), which still leaves the handler open for further use.


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

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

From noreply at sourceforge.net  Sat Feb 21 19:13:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 21 19:15:34 2004
Subject: [ python-Bugs-901654 ] split method documentation can be improved
Message-ID: <E1AuhFX-000718-00@sc8-sf-web3.sourceforge.net>

Bugs item #901654, was opened at 2004-02-21 18:22
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901654&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Raymond Hettinger (rhettinger)
Summary: split method documentation can be improved

Initial Comment:
If you compare the documentation for the string.split
function and the split method on strings, you'll find
the former much clearer in the description of what
happens with a None separator argument.  The doc
strings of both are like the method, not terribly precise.

It may be worth it to compare other string methods /
string module functions.

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

Comment By: George Yoshida (quiver)
Date: 2004-02-22 09:13

Message:
Logged In: YES 
user_id=671362

This one is related to bug # 811604.
 "string".split behaviour for empty strings
 http://www.python.org/sf/811604

I think the doc change will also close the bug #811604.

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

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

From noreply at sourceforge.net  Sun Feb 22 03:13:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb 22 03:14:56 2004
Subject: [ python-Bugs-902037 ] relative on-disk SYSTEM id handling is
	incorrect
Message-ID: <E1AuojY-0007dr-00@sc8-sf-web4.sourceforge.net>

Bugs item #902037, was opened at 2004-02-22 03:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902037&group_id=5470

Category: XML
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: relative on-disk SYSTEM id handling is incorrect

Initial Comment:
XML.sax.saxutils.prepare_input_source checks os.path.isfile on a 
relative path without first combining it with the base path.  
Attached patch is against CVS HEAD (which is also broken, 
in the exact same way, so I imagine the patch should apply cleanly 
to 2.3).

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

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

From noreply at sourceforge.net  Sun Feb 22 04:29:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb 22 04:31:57 2004
Subject: [ python-Bugs-902061 ] pydoc insists upon producing file: URLs
Message-ID: <E1Aupvz-0006F9-00@sc8-sf-web2.sourceforge.net>

Bugs item #902061, was opened at 2004-02-22 09:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902061&group_id=5470

Category: Demos and Tools
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc insists upon producing file: URLs

Initial Comment:
[forwarded from http://bugs.debian.org/230572]

In method docmodule() of class HTMLdoc, a href is
produced to the source code of the current module.

First of all, it is produced as a file: URL, so it is
incorrect on any computer other than the server.

Second, it is a minor security breach, because it
displays information about the directory structure of
the computer on which it is running.

Now, normally, you'd run pydoc so that it would only
serve files locally, and the current behavior is not
too bad.  However, the program ought to be made more
flexible so that it can also be used in other ways.

I'd suggest replacing this line:

            filelink = '<a href="file:%s">%s</a>' %
(url, path)

with a function call, so that the behavior of the
program can be easily modified:

	    filelink = source_code_link(url, path)

def source_code_link(url, path):
	...

One could then make the behavior of source_code_link()
controllable from the command line via a global
variable, or just let people who want to modify the
behavior simply replace source_code_link() with their
own function.

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

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

From noreply at sourceforge.net  Sun Feb 22 04:41:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb 22 04:43:22 2004
Subject: [ python-Bugs-902065 ] fails building C++ extensions when
	configured --without-cxx
Message-ID: <E1Auq79-0001pm-00@sc8-sf-web4.sourceforge.net>

Bugs item #902065, was opened at 2004-02-22 09:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902065&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: fails building C++ extensions when configured --without-cxx

Initial Comment:
building C++ extensions with python configured
--without-cxx fails, because the installed
config/Makefile has CXX set to the empty string.
However at least on Linux it does work to build the
python binary without C++ for not depending on
libstdc++ but load/build a module which depends on
libstdc++ (which gets linked by g++).

Editing the generated config/Makefile does solve the
problem.
Another solution might be to pass LDSHARED in the
environment to distutils as it is already done for CC,
CFLAGS, etc, but this requires interaction by the
builder of the module.

--- Lib/distutils/sysconfig.py~ 2003-02-10
15:02:33.000000000 +0100
+++ Lib/distutils/sysconfig.py  2004-02-03
10:53:21.000000000 +0100
@@ -153,6 +153,10 @@
             cc = os.environ['CC']
         if os.environ.has_key('CXX'):
             cxx = os.environ['CXX']
+        if os.environ.has_key('LDSHARED'):
+            ldshared = os.environ['LDSHARED']
+        if os.environ.has_key('CCSHARED'):
+            ccshared = os.environ['CCSHARED']
         if os.environ.has_key('CPP'):
             cpp = os.environ['CPP']
         else:


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

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

From noreply at sourceforge.net  Sun Feb 22 05:05:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb 22 05:07:15 2004
Subject: [ python-Bugs-902075 ] urllib2 should be more robust for sloppy
	proxy URLs
Message-ID: <E1AuqUA-0007PD-00@sc8-sf-web2.sourceforge.net>

Bugs item #902075, was opened at 2004-02-22 10:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902075&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 should be more robust for sloppy proxy URLs

Initial Comment:
passing an URL like "foo.bar.baz" instead of
"http://foo.bar.baz" results in a stacktrace:

  File "/usr/lib/python2.3/urllib2.py", line 326, in open
    '_open', req)
  File "/usr/lib/python2.3/urllib2.py", line 306, in
_call_chain
    result = func(*args)
  File "/usr/lib/python2.3/urllib2.py", line 491, in
<lambda>
    lambda r, proxy=url, type=type, meth=self.proxy_open:   File "/usr/lib/python2.3/urllib2.py", line 498, in
proxy_open
    if '@' in host:
TypeError: iterable argument required

This could be fixed by calling urlparse.urlparse on the
proxy url, either in the calling code or in the library
code, which I would prefer to make it more robust about
sloppy URLs passed in the http_proxy environment variable.


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

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

From noreply at sourceforge.net  Sun Feb 22 05:19:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb 22 05:21:49 2004
Subject: [ python-Bugs-902075 ] urllib2 should be more robust for sloppy
	proxy URLs
Message-ID: <E1AuqiF-0002yJ-00@sc8-sf-web4.sourceforge.net>

Bugs item #902075, was opened at 2004-02-22 10:05
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902075&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 should be more robust for sloppy proxy URLs

Initial Comment:
passing an URL like "foo.bar.baz" instead of
"http://foo.bar.baz" results in a stacktrace:

  File "/usr/lib/python2.3/urllib2.py", line 326, in open
    '_open', req)
  File "/usr/lib/python2.3/urllib2.py", line 306, in
_call_chain
    result = func(*args)
  File "/usr/lib/python2.3/urllib2.py", line 491, in
<lambda>
    lambda r, proxy=url, type=type, meth=self.proxy_open:   File "/usr/lib/python2.3/urllib2.py", line 498, in
proxy_open
    if '@' in host:
TypeError: iterable argument required

This could be fixed by calling urlparse.urlparse on the
proxy url, either in the calling code or in the library
code, which I would prefer to make it more robust about
sloppy URLs passed in the http_proxy environment variable.


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

>Comment By: Matthias Klose (doko)
Date: 2004-02-22 10:19

Message:
Logged In: YES 
user_id=60903

Ok, I see, PEP42 ...


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

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

From noreply at sourceforge.net  Sun Feb 22 10:21:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb 22 10:23:06 2004
Subject: [ python-Bugs-902151 ] Thread start - strange error under Cygwin
Message-ID: <E1AuvPt-0002TS-00@sc8-sf-web1.sourceforge.net>

Bugs item #902151, was opened at 2004-02-22 16:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902151&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Artur de Sousa Rocha (adsr)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread start - strange error under Cygwin

Initial Comment:
I wrote a short script that launches several threads 
(parallel download using urllib.urlretrieve in this case). 
Sometimes when I launch my script under Cygwin, I get 
strange error messages like:

      2 [win] python 1912 Winmain: Cannot register 
window class

Sometimes all of the threads run OK, otherwise after 
the "correct" ones finish the console stops responding.

No problems with this script directly under Windows

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

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

From noreply at sourceforge.net  Sun Feb 22 11:09:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb 22 11:11:13 2004
Subject: [ python-Bugs-902172 ] Timezone miscalculation (time.mktime)
Message-ID: <E1AuwAV-0004NG-00@sc8-sf-web3.sourceforge.net>

Bugs item #902172, was opened at 2004-02-22 18:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902172&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Marti Raudsepp (sipsick)
Assigned to: Nobody/Anonymous (nobody)
Summary: Timezone miscalculation (time.mktime)

Initial Comment:
The problem:
time.mktime(time.gmtime(0)) - time.timezone == -3600.
0
(Should be 0.0 if I understood it right)

Python seems to miscalculate the local time when using 
mktime. The problem appeared when one of the runtests 
in MoinMoin failed (spefically MoinMoin._tests.
test_parser_wiki.WikiMacroTestCase)

I used two machines for testing:
1. NetBSD 1.6.1 (GENERIC), Python version 2.3.3 (#1, 
Feb 20 2004, 00:53:29) [GCC 2.95.3 20010315 (release) 
(NetBSD nb3)]
2. Linux 2.4.20-3-686 (Debian GNU/Linux), Python 
version 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 
20040110 (prerelease) (Debian)]

Both machine generate the identical error:
AssertionError: Expected '1#1970-01-06 00:00:00#1' in:
1#1970-01-05 23:00:00#1 [...]

A few simple tests in the python shell (both machines)
>>> import time
>>> time.daylight
1
>>> time.timezone
-7200
>>> time.tzname
('EET', 'EEST')
>>> time.mktime(time.localtime(0))
0.0
>>> time.mktime(time.gmtime(0)) - time.timezone
-3600.0
>>> time.gmtime(0)
(1970, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.
timezone
-3600.0
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, -1)) - time.
timezone
-3600.0


However, the only difference between the Linux and BSD 
machine is:
1. NetBSD
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-7200.0
2. Linux
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-3600.0

I also attached the results of the moin test just in case.

--
Marti

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

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

From noreply at sourceforge.net  Sun Feb 22 11:11:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Feb 22 11:17:06 2004
Subject: [ python-Bugs-902172 ] Timezone miscalculation (time.mktime)
Message-ID: <E1AuwCt-0004Tj-00@sc8-sf-web3.sourceforge.net>

Bugs item #902172, was opened at 2004-02-22 18:09
Message generated for change (Comment added) made by sipsick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902172&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Marti Raudsepp (sipsick)
Assigned to: Nobody/Anonymous (nobody)
Summary: Timezone miscalculation (time.mktime)

Initial Comment:
The problem:
time.mktime(time.gmtime(0)) - time.timezone == -3600.
0
(Should be 0.0 if I understood it right)

Python seems to miscalculate the local time when using 
mktime. The problem appeared when one of the runtests 
in MoinMoin failed (spefically MoinMoin._tests.
test_parser_wiki.WikiMacroTestCase)

I used two machines for testing:
1. NetBSD 1.6.1 (GENERIC), Python version 2.3.3 (#1, 
Feb 20 2004, 00:53:29) [GCC 2.95.3 20010315 (release) 
(NetBSD nb3)]
2. Linux 2.4.20-3-686 (Debian GNU/Linux), Python 
version 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 
20040110 (prerelease) (Debian)]

Both machine generate the identical error:
AssertionError: Expected '1#1970-01-06 00:00:00#1' in:
1#1970-01-05 23:00:00#1 [...]

A few simple tests in the python shell (both machines)
>>> import time
>>> time.daylight
1
>>> time.timezone
-7200
>>> time.tzname
('EET', 'EEST')
>>> time.mktime(time.localtime(0))
0.0
>>> time.mktime(time.gmtime(0)) - time.timezone
-3600.0
>>> time.gmtime(0)
(1970, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.
timezone
-3600.0
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, -1)) - time.
timezone
-3600.0


However, the only difference between the Linux and BSD 
machine is:
1. NetBSD
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-7200.0
2. Linux
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-3600.0

I also attached the results of the moin test just in case.

--
Marti

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

>Comment By: Marti Raudsepp (sipsick)
Date: 2004-02-22 18:11

Message:
Logged In: YES 
user_id=345221

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

Please try again.

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

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

Comment By: Marti Raudsepp (sipsick)
Date: 2004-02-22 18:11

Message:
Logged In: YES 
user_id=345221

Oops, forgot to check the upload box :)

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

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

From noreply at sourceforge.net  Mon Feb 23 02:37:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 23 02:39:26 2004
Subject: [ python-Bugs-902501 ] Encodings: koi8-u.py -- errata in decoding
	map
Message-ID: <E1AvAeb-0001p3-00@sc8-sf-web4.sourceforge.net>

Bugs item #902501, was opened at 2004-02-23 09:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902501&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belchenko (bialix)
Assigned to: Nobody/Anonymous (nobody)
Summary: Encodings: koi8-u.py -- errata in decoding map

Initial Comment:
File koi8-u.py in /Lib/encodings/koi8-u.py has errata.
Decoding map dictionary update for ukrainian letter
"CYRILLIC CAPITAL LETTER UKRAINIAN IE" is 
***
0x00b4: 0x0403, #       CYRILLIC CAPITAL LETTER
UKRAINIAN IE
***

Must be Unicode representation - 0x0404 instead of 0x0403.

Reference: RFC2319 (look at
ftp://ftp.lucky.net/pub/koi8-u/RFC2319.txt
and
ftp://ftp.unicode.org/Public/4.0-Update1/UnicodeData-4.0.1d3b.txt)

Other cyrilic decoding map is correct.

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

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

From noreply at sourceforge.net  Mon Feb 23 04:05:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 23 04:07:27 2004
Subject: [ python-Bugs-902501 ] Encodings: koi8-u.py -- errata in decoding
	map
Message-ID: <E1AvC1h-00006q-00@sc8-sf-web3.sourceforge.net>

Bugs item #902501, was opened at 2004-02-23 08:37
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902501&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alexander Belchenko (bialix)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: Encodings: koi8-u.py -- errata in decoding map

Initial Comment:
File koi8-u.py in /Lib/encodings/koi8-u.py has errata.
Decoding map dictionary update for ukrainian letter
"CYRILLIC CAPITAL LETTER UKRAINIAN IE" is 
***
0x00b4: 0x0403, #       CYRILLIC CAPITAL LETTER
UKRAINIAN IE
***

Must be Unicode representation - 0x0404 instead of 0x0403.

Reference: RFC2319 (look at
ftp://ftp.lucky.net/pub/koi8-u/RFC2319.txt
and
ftp://ftp.unicode.org/Public/4.0-Update1/UnicodeData-4.0.1d3b.txt)

Other cyrilic decoding map is correct.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-23 10:05

Message:
Logged In: YES 
user_id=38388

Thanks.

Checking in koi8_u.py;
/cvsroot/python/python/dist/src/Lib/encodings/koi8_u.py,v 
<--  koi8_u.py
new revision: 1.2; previous revision: 1.1


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

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

From noreply at sourceforge.net  Mon Feb 23 04:14:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 23 04:20:15 2004
Subject: [ python-Bugs-902172 ] Timezone miscalculation (time.mktime)
Message-ID: <E1AvCAz-0000cj-00@sc8-sf-web3.sourceforge.net>

Bugs item #902172, was opened at 2004-02-22 11:09
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902172&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Marti Raudsepp (sipsick)
>Assigned to: Brett Cannon (bcannon)
Summary: Timezone miscalculation (time.mktime)

Initial Comment:
The problem:
time.mktime(time.gmtime(0)) - time.timezone == -3600.
0
(Should be 0.0 if I understood it right)

Python seems to miscalculate the local time when using 
mktime. The problem appeared when one of the runtests 
in MoinMoin failed (spefically MoinMoin._tests.
test_parser_wiki.WikiMacroTestCase)

I used two machines for testing:
1. NetBSD 1.6.1 (GENERIC), Python version 2.3.3 (#1, 
Feb 20 2004, 00:53:29) [GCC 2.95.3 20010315 (release) 
(NetBSD nb3)]
2. Linux 2.4.20-3-686 (Debian GNU/Linux), Python 
version 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 
20040110 (prerelease) (Debian)]

Both machine generate the identical error:
AssertionError: Expected '1#1970-01-06 00:00:00#1' in:
1#1970-01-05 23:00:00#1 [...]

A few simple tests in the python shell (both machines)
>>> import time
>>> time.daylight
1
>>> time.timezone
-7200
>>> time.tzname
('EET', 'EEST')
>>> time.mktime(time.localtime(0))
0.0
>>> time.mktime(time.gmtime(0)) - time.timezone
-3600.0
>>> time.gmtime(0)
(1970, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.
timezone
-3600.0
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, -1)) - time.
timezone
-3600.0


However, the only difference between the Linux and BSD 
machine is:
1. NetBSD
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-7200.0
2. Linux
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-3600.0

I also attached the results of the moin test just in case.

--
Marti

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

Comment By: Marti Raudsepp (sipsick)
Date: 2004-02-22 11:11

Message:
Logged In: YES 
user_id=345221

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

Please try again.

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

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

Comment By: Marti Raudsepp (sipsick)
Date: 2004-02-22 11:11

Message:
Logged In: YES 
user_id=345221

Oops, forgot to check the upload box :)

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

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

From noreply at sourceforge.net  Mon Feb 23 07:10:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 23 07:12:14 2004
Subject: [ python-Bugs-902628 ] doctest confused by super-instances in
	class-dicts
Message-ID: <E1AvEuW-0001xr-00@sc8-sf-web2.sourceforge.net>

Bugs item #902628, was opened at 2004-02-23 12:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902628&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Tanzer (tanzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest confused by super-instances in class-dicts

Initial Comment:
In Python 2.3.3, doctest chokes on classes which
contain an attribute of type super: 

Traceback (most recent call last):
  File "/ttt/private/tanzer/temp/confuse_doctest.py",
line 14, in ?
    import doctest, confuse_doctest
  File
"/Node/tttprime/ttt/private/tanzer/temp/confuse_doctest.py",
line 15, in ?
    doctest.testmod(confuse_doctest)
  File "/usr/lib/python2.3/doctest.py", line 1148, in
testmod
    f, t = tester.rundict(m.__dict__, name, m)
  File "/usr/lib/python2.3/doctest.py", line 908, in
rundict
    f2, t2 = self.__runone(value, name + "." + thisname)
  File "/usr/lib/python2.3/doctest.py", line 1069, in
__runone
    return self.rundoc(target, name)
  File "/usr/lib/python2.3/doctest.py", line 828, in rundoc
    f2, t2 = self.run__test__(d, name)
  File "/usr/lib/python2.3/doctest.py", line 937, in
run__test__
    raise TypeError("Tester.run__test__: values in "
TypeError: Tester.run__test__: values in dict must be
strings, functions, methods, or classes; <super: <class
'A'>, NULL>

A simple example triggering the bug is attached.

Python 2.3.3 (#2, Jan 13 2004, 00:47:05) 
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2



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

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

From noreply at sourceforge.net  Mon Feb 23 07:15:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 23 07:17:29 2004
Subject: [ python-Bugs-902628 ] doctest confused by super-instances in
	class-dicts
Message-ID: <E1AvEza-0002D8-00@sc8-sf-web2.sourceforge.net>

Bugs item #902628, was opened at 2004-02-23 12:10
Message generated for change (Comment added) made by tanzer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902628&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Tanzer (tanzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest confused by super-instances in class-dicts

Initial Comment:
In Python 2.3.3, doctest chokes on classes which
contain an attribute of type super: 

Traceback (most recent call last):
  File "/ttt/private/tanzer/temp/confuse_doctest.py",
line 14, in ?
    import doctest, confuse_doctest
  File
"/Node/tttprime/ttt/private/tanzer/temp/confuse_doctest.py",
line 15, in ?
    doctest.testmod(confuse_doctest)
  File "/usr/lib/python2.3/doctest.py", line 1148, in
testmod
    f, t = tester.rundict(m.__dict__, name, m)
  File "/usr/lib/python2.3/doctest.py", line 908, in
rundict
    f2, t2 = self.__runone(value, name + "." + thisname)
  File "/usr/lib/python2.3/doctest.py", line 1069, in
__runone
    return self.rundoc(target, name)
  File "/usr/lib/python2.3/doctest.py", line 828, in rundoc
    f2, t2 = self.run__test__(d, name)
  File "/usr/lib/python2.3/doctest.py", line 937, in
run__test__
    raise TypeError("Tester.run__test__: values in "
TypeError: Tester.run__test__: values in dict must be
strings, functions, methods, or classes; <super: <class
'A'>, NULL>

A simple example triggering the bug is attached.

Python 2.3.3 (#2, Jan 13 2004, 00:47:05) 
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2



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

>Comment By: Christian Tanzer (tanzer)
Date: 2004-02-23 12:15

Message:
Logged In: YES 
user_id=2402

I patched doctest.py to avoid the traceback (see attached
patch-file). I'm not sure if this is the right place to fix
the bug, though. Maybe inspect.classify_class_attrs should
be changed instead?

The second chunk of the patch improves the traceback given
by doctest by giving the name of the offending dict-item.

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

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

From noreply at sourceforge.net  Mon Feb 23 16:18:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 23 16:20:21 2004
Subject: [ python-Bugs-902998 ] help("exec") doesn't work
Message-ID: <E1AvNSr-0007BU-00@sc8-sf-web1.sourceforge.net>

Bugs item #902998, was opened at 2004-02-23 21:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902998&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Lynn (tlynn)
Assigned to: Nobody/Anonymous (nobody)
Summary: help("exec") doesn't work

Initial Comment:
(I get this behaviour on Win2k and two Linux installs.)

Python 2.3.2 (#3, Nov 30 2003, 19:53:06)
[GCC 3.1] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> help("eval")
Help on built-in function eval:

eval(...)
    eval(source[, globals[, locals]]) -> value

    Evaluate the source in the context of globals and 
locals.
    The source may be a string representing a Python 
expression
    or a code object as returned by compile().
    The globals and locals are dictionaries, defaulting to 
the current
    globals and locals.  If only globals is given, locals 
defaults to it.

>>> help("exec")

Sorry, topic and keyword documentation is not available 
because the Python
HTML documentation files could not be found.  If you 
have installed them,
please set the environment variable PYTHONDOCS to 
indicate their location.

>>>


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

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

From noreply at sourceforge.net  Mon Feb 23 16:28:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 23 16:34:28 2004
Subject: [ python-Bugs-902998 ] help("exec") doesn't work
Message-ID: <E1AvNd5-0005zB-00@sc8-sf-web2.sourceforge.net>

Bugs item #902998, was opened at 2004-02-23 21:18
Message generated for change (Settings changed) made by tlynn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902998&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Lynn (tlynn)
Assigned to: Nobody/Anonymous (nobody)
>Summary: help("exec") doesn't work

Initial Comment:
(I get this behaviour on Win2k and two Linux installs.)

Python 2.3.2 (#3, Nov 30 2003, 19:53:06)
[GCC 3.1] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> help("eval")
Help on built-in function eval:

eval(...)
    eval(source[, globals[, locals]]) -> value

    Evaluate the source in the context of globals and 
locals.
    The source may be a string representing a Python 
expression
    or a code object as returned by compile().
    The globals and locals are dictionaries, defaulting to 
the current
    globals and locals.  If only globals is given, locals 
defaults to it.

>>> help("exec")

Sorry, topic and keyword documentation is not available 
because the Python
HTML documentation files could not be found.  If you 
have installed them,
please set the environment variable PYTHONDOCS to 
indicate their location.

>>>


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

Comment By: Tom Lynn (tlynn)
Date: 2004-02-23 21:27

Message:
Logged In: YES 
user_id=915320

">>> import keyword
>>> for word in keyword.kwlist: print word; help(word)
...
and

Sorry, topic and keyword "...
(further sorrow ensues for all the other keywords too)


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

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

From noreply at sourceforge.net  Mon Feb 23 16:27:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 23 16:36:51 2004
Subject: [ python-Bugs-902998 ] help(
Message-ID: <E1AvNba-0005tb-00@sc8-sf-web2.sourceforge.net>

Bugs item #902998, was opened at 2004-02-23 21:18
Message generated for change (Comment added) made by tlynn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902998&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Lynn (tlynn)
Assigned to: Nobody/Anonymous (nobody)
>Summary: help(

Initial Comment:
(I get this behaviour on Win2k and two Linux installs.)

Python 2.3.2 (#3, Nov 30 2003, 19:53:06)
[GCC 3.1] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> help("eval")
Help on built-in function eval:

eval(...)
    eval(source[, globals[, locals]]) -> value

    Evaluate the source in the context of globals and 
locals.
    The source may be a string representing a Python 
expression
    or a code object as returned by compile().
    The globals and locals are dictionaries, defaulting to 
the current
    globals and locals.  If only globals is given, locals 
defaults to it.

>>> help("exec")

Sorry, topic and keyword documentation is not available 
because the Python
HTML documentation files could not be found.  If you 
have installed them,
please set the environment variable PYTHONDOCS to 
indicate their location.

>>>


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

>Comment By: Tom Lynn (tlynn)
Date: 2004-02-23 21:27

Message:
Logged In: YES 
user_id=915320

">>> import keyword
>>> for word in keyword.kwlist: print word; help(word)
...
and

Sorry, topic and keyword "...
(further sorrow ensues for all the other keywords too)


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

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

From noreply at sourceforge.net  Mon Feb 23 16:35:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 23 16:37:21 2004
Subject: [ python-Bugs-902998 ] help("exec") doesn't work
Message-ID: <E1AvNjV-0002Wi-00@sc8-sf-web3.sourceforge.net>

Bugs item #902998, was opened at 2004-02-23 21:18
Message generated for change (Comment added) made by tlynn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902998&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
>Priority: 1
Submitted By: Tom Lynn (tlynn)
Assigned to: Nobody/Anonymous (nobody)
Summary: help("exec") doesn't work

Initial Comment:
(I get this behaviour on Win2k and two Linux installs.)

Python 2.3.2 (#3, Nov 30 2003, 19:53:06)
[GCC 3.1] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> help("eval")
Help on built-in function eval:

eval(...)
    eval(source[, globals[, locals]]) -> value

    Evaluate the source in the context of globals and 
locals.
    The source may be a string representing a Python 
expression
    or a code object as returned by compile().
    The globals and locals are dictionaries, defaulting to 
the current
    globals and locals.  If only globals is given, locals 
defaults to it.

>>> help("exec")

Sorry, topic and keyword documentation is not available 
because the Python
HTML documentation files could not be found.  If you 
have installed them,
please set the environment variable PYTHONDOCS to 
indicate their location.

>>>


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

>Comment By: Tom Lynn (tlynn)
Date: 2004-02-23 21:35

Message:
Logged In: YES 
user_id=915320

Doh.  Ok, so I feel stupid.

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

Comment By: Tom Lynn (tlynn)
Date: 2004-02-23 21:27

Message:
Logged In: YES 
user_id=915320

">>> import keyword
>>> for word in keyword.kwlist: print word; help(word)
...
and

Sorry, topic and keyword "...
(further sorrow ensues for all the other keywords too)


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

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

From noreply at sourceforge.net  Mon Feb 23 22:05:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 23 22:07:14 2004
Subject: [ python-Bugs-897817 ] test_strptime failures on FC2-test
Message-ID: <E1AvSsb-0005Ia-00@sc8-sf-web4.sourceforge.net>

Bugs item #897817, was opened at 2004-02-16 16:52
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897817&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: test_strptime failures on FC2-test

Initial Comment:
I&#039;m seeing test_strptime failures on this box, running
a version of Fedora Core that&#039;s between 1 and the new
test release.

test test_strptime failed -- Traceback (most recent
call last): 
File "Lib/test/test_strptime.py", line 258, in
test_timezone
    self.failUnlessEqual(strp_output.tm_isdst, 0)
AssertionError: -1 != 0

Note that the following line (which tests GMT) also
fails with a -1.

The underlying failure:
>>> import _strptime
>>> strp_output = _strptime.strptime("UTC", "%Z")
>>> strp_output.tm_isdst
-1
>>> strp_output = _strptime.strptime("GMT", "%Z")
>>> strp_output.tm_isdst
-1


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

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-02-24 14:05

Message:
Logged In: YES 
user_id=29957

Very very strange. I rebuilt python, and the problem has
gone away. I will assign this to myself and try and
reproduce it. 

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-18 08:39

Message:
Logged In: YES 
user_id=357491

Anthony, can you let me know what the following commands spit out?::

import time; import _strptime
time.tzname
time.daylight
_strptime.LocaleTime().timezone
_strptime.TimeRE()['Z']

That should be enough info for me to debug this.

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

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

From noreply at sourceforge.net  Mon Feb 23 23:26:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Feb 23 23:28:45 2004
Subject: [ python-Bugs-897817 ] test_strptime failures on FC2-test
Message-ID: <E1AvU9P-0006yg-00@sc8-sf-web2.sourceforge.net>

Bugs item #897817, was opened at 2004-02-15 21:52
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897817&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: test_strptime failures on FC2-test

Initial Comment:
I&#039;m seeing test_strptime failures on this box, running
a version of Fedora Core that&#039;s between 1 and the new
test release.

test test_strptime failed -- Traceback (most recent
call last): 
File "Lib/test/test_strptime.py", line 258, in
test_timezone
    self.failUnlessEqual(strp_output.tm_isdst, 0)
AssertionError: -1 != 0

Note that the following line (which tests GMT) also
fails with a -1.

The underlying failure:
>>> import _strptime
>>> strp_output = _strptime.strptime("UTC", "%Z")
>>> strp_output.tm_isdst
-1
>>> strp_output = _strptime.strptime("GMT", "%Z")
>>> strp_output.tm_isdst
-1


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-02-23 20:26

Message:
Logged In: YES 
user_id=357491

A possible cause for this, Anthony, is having the timezone set to ("UTC", 
"GMT") and time.daylight to a 1.  This would lead to not passing the test 
since there is an explicit test in the strptime code for when duplicate 
non-DST and DST timezones are the same and this would do it since UTC 
and GMT are injected into the non-DST timezone list for comparisons.  
The default is -1 since you can't tell the proper value if both non-DST and 
DST are the same.  And UTC and GMT should not be considered DST 
timezones obviously.

Anyway, I hope you don't find anything wrong and it was just a weird 
glitch in the date settings.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-02-23 19:05

Message:
Logged In: YES 
user_id=29957

Very very strange. I rebuilt python, and the problem has
gone away. I will assign this to myself and try and
reproduce it. 

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 13:39

Message:
Logged In: YES 
user_id=357491

Anthony, can you let me know what the following commands spit out?::

import time; import _strptime
time.tzname
time.daylight
_strptime.LocaleTime().timezone
_strptime.TimeRE()['Z']

That should be enough info for me to debug this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897817&group_id=5470

From noreply at sourceforge.net  Tue Feb 24 03:36:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 24 03:42:09 2004
Subject: [ python-Bugs-902172 ] Timezone miscalculation (time.mktime)
Message-ID: <E1AvY3X-00018L-00@sc8-sf-web4.sourceforge.net>

Bugs item #902172, was opened at 2004-02-22 08:09
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902172&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Marti Raudsepp (sipsick)
Assigned to: Brett Cannon (bcannon)
Summary: Timezone miscalculation (time.mktime)

Initial Comment:
The problem:
time.mktime(time.gmtime(0)) - time.timezone == -3600.
0
(Should be 0.0 if I understood it right)

Python seems to miscalculate the local time when using 
mktime. The problem appeared when one of the runtests 
in MoinMoin failed (spefically MoinMoin._tests.
test_parser_wiki.WikiMacroTestCase)

I used two machines for testing:
1. NetBSD 1.6.1 (GENERIC), Python version 2.3.3 (#1, 
Feb 20 2004, 00:53:29) [GCC 2.95.3 20010315 (release) 
(NetBSD nb3)]
2. Linux 2.4.20-3-686 (Debian GNU/Linux), Python 
version 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 
20040110 (prerelease) (Debian)]

Both machine generate the identical error:
AssertionError: Expected &#039;1#1970-01-06 00:00:00#1&#039; in:
1#1970-01-05 23:00:00#1 [...]

A few simple tests in the python shell (both machines)
>>> import time
>>> time.daylight
1
>>> time.timezone
-7200
>>> time.tzname
(&#039;EET&#039;, &#039;EEST&#039;)
>>> time.mktime(time.localtime(0))
0.0
>>> time.mktime(time.gmtime(0)) - time.timezone
-3600.0
>>> time.gmtime(0)
(1970, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.
timezone
-3600.0
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, -1)) - time.
timezone
-3600.0


However, the only difference between the Linux and BSD 
machine is:
1. NetBSD
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-7200.0
2. Linux
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-3600.0

I also attached the results of the moin test just in case.

--
Marti

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-02-24 00:36

Message:
Logged In: YES 
user_id=357491

OK, what I need is the result for ``time.localtime(0)`` (according to the 
calculations above should be three hours ahead of UTC, but in actuality, 
as long as the DST field is 0, should only be two hours ahead for EET) 
and ``time.mktime(time.gmtime(0))`` (should be -10800 according to 
the calculations above, but I want to double-check).  And the value of 
``time.altzone`` wouldn't hurt for trying to deal with the slight 
difference between the two OSs (should be -3600, or 1 hour ahead of 
UTC, for DST in EET, right?  In other words, EET is two hours ahead of 
UTC normally and only one hour ahead during daylight savings).

It looks like time.localtime(0) is off by an hour for some odd reason.  
And as for the discrepency between platforms, it should be only an hour 
difference since you should be subtracting time.altzone with the DST flag 
set to 1 and not time.timezone .  So it looks like Linux is behaving 
correctly and NetBSD is being really screwy if that is the only difference 
between the platforms.

But, to be honest, from a quick glance and the code, the wrappers are so 
thin that I don't think it is going to be on our side.  But with the info 
above I should be able to figure out where the discrepency is coming 
from and be able to make sure whose fault it is.

----------------------------------------------------------------------

Comment By: Marti Raudsepp (sipsick)
Date: 2004-02-22 08:11

Message:
Logged In: YES 
user_id=345221

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

Comment By: Marti Raudsepp (sipsick)
Date: 2004-02-22 08:11

Message:
Logged In: YES 
user_id=345221

Oops, forgot to check the upload box :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902172&group_id=5470

From noreply at sourceforge.net  Tue Feb 24 04:29:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 24 04:32:14 2004
Subject: [ python-Bugs-848871 ] Windows installer halts
Message-ID: <E1AvYt3-0003pD-00@sc8-sf-web4.sourceforge.net>

Bugs item #848871, was opened at 2003-11-25 12:38
Message generated for change (Comment added) made by morr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848871&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jens Olsson (morr)
Assigned to: Thomas Heller (theller)
Summary: Windows installer halts

Initial Comment:
The Windows installer halts when starting to install files, 
more exactly when installing the file "UNWISE.EXE" and 
the progress bar reads "1%".

Python versions tested:
2.2.3
2.3.1
2.3.2
2.3.2-1

All tested versions behave the same. Since I don&#039;t believe 
it&#039;s a common bug I attach selected computer specs for 
the system in question. I find it hard to believe it is the 
python windows installer by itself that contains the bug 
but since I haven&#039;t experienced this with any other 
installer I submit the bug anyway. It can&#039;t be my system 
by itself either.

- Varying the installation options does not seem to help 
(non exhaustive testing done).
- Running install on on specific processor (Hyper 
Threading is enabled) does not change things

Test system summary (see attachment for full specs):
Gigabyte 8KNXP motherboard, intel Northwood 3.0GHz HT, 
2x512MB Corsair 3500, Radeon 9700 AIW, Seagate 
Barracuda 160GB, Windows XP Pro SP1a.

Reproduction steps:
1. Launch installer
2. Click &#039;next&#039; when asked for directory
3. Click &#039;next&#039; when asked about backups
4. Click &#039;next&#039; when asked for component selection
5. Click &#039;next&#039; when asked for start menu group selection
6. Click &#039;next&#039; when prompted with the "ready to install" 
screen
7. Observere bug


----------------------------------------------------------------------

>Comment By: Jens Olsson (morr)
Date: 2004-02-24 10:29

Message:
Logged In: YES 
user_id=917179

Any news on this one? Latest version behaves the same. Is 
there any alternative Windows install procedure that is 
reasonable easy to perform?

----------------------------------------------------------------------

Comment By: Jens Olsson (morr)
Date: 2003-12-10 12:38

Message:
Logged In: YES 
user_id=917179

I couldn't update comments and didn't have time to figure out 
how I should do it so I hope this attached file will do.

Follow up:

I ran the installer with the suggested /m1 option. The install 
asked for the following directories (in order):

windows 
system
system32
temp
source

All input boxes had default values which seemed reasonable so 
I left them unchanged.

Then the actual installer window showed (as without /m1). 
After submitting the requested information (as reported in the 
inital bugreport) the installer halted when the small window 
titled "installing" showed, at 1% and the file unwise.exe... just 
as before. No question about registring files (besides the five 
windows promting for manual input of directories as described 
above).

No error messages. Just the same behaviour as before with 
some additional directory prompting dialoges at the beginning.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-12-05 20:49

Message:
Logged In: YES 
user_id=11105

Here is advice I got from a Wise rep:

"""
This sounds like it is hanging at the point that the install
is trying to self register files. You can test this by
running the setup.exe with a /m1.  This will run the install
in manual mode, and prompt when each file is trying to self
register.  This will indicate which file it is trying to
self register, and then the error message.
"""

Can you try this, please, and report the result?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-12-03 21:58

Message:
Logged In: YES 
user_id=11105

I've asked in the WISE support news group for help, I've
also seen similar behaviour in other software built with WISE.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848871&group_id=5470

From noreply at sourceforge.net  Tue Feb 24 05:20:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 24 05:22:40 2004
Subject: [ python-Bugs-903339 ] OpenVMS file system and UNIVERSAL_NEWLINES
	support
Message-ID: <E1AvZg2-00071h-00@sc8-sf-web1.sourceforge.net>

Bugs item #903339, was opened at 2004-02-24 11:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903339&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Pi?ronne Jean-Fran?ois (pieronne)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenVMS file system and UNIVERSAL_NEWLINES support

Initial Comment:
I am one of the maintainer of Python on OpenVMS.

Building from time to time Python 2.4 from CVS
snapshot, I have just noticed that all the conditional
compilation against WITH_UNIVERSAL_NEWLINES has been
removed.

This is a major problem on OpenVMS.

VMS has a complex file system which is mostly record
oriented and not stream oriented (even if it support
stream oriented files, this is not the default).
For example it support the following record formats:
fixed-length, variable-length, variable with
fixed-length control, 3 stream format, etc...
The default is variable-length.

So reading (opening) text file, for example during a
import, in binary mode lead to incorrect results
because there are no &#039;\n&#039; or any character (or
combinaison of characters) at the end of the line.
If the file is not open in binary mode the VMS CRTL
automatically append a &#039;\n&#039; at the end of the record,
so all work correctly. This not the case in binary
mode, in this case the record is read as is, in fact
you even get the control part of the record for some
record format.

So, is it possible to maintain this test, even as
undocumented or is it acceptable to transform it into a
specific VMS test. But I suspect that other mainframe
file systems will have the same problem.

Thanks for any help.

Regards,

Jean-Fran?ois 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903339&group_id=5470

From noreply at sourceforge.net  Tue Feb 24 07:03:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 24 07:05:38 2004
Subject: [ python-Bugs-629097 ] Race condition in asyncore poll
Message-ID: <E1AvbHa-00045G-00@sc8-sf-web4.sourceforge.net>

Bugs item #629097, was opened at 2002-10-26 18:48
Message generated for change (Comment added) made by klimkin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629097&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Nobody/Anonymous (nobody)
Summary: Race condition in asyncore poll

Initial Comment:
In the following post to the Zope 3 developers&#039; list, I
describe a race condition in the poll method of asyncore.

http://lists.zope.org/pipermail/zope3-dev/2002-October/003091.html

The problem is this:

There is a global dict socket_map. In the poll method,
socket_map is processed into appropriate arguments for
a select.select call. However, if a socket that is
represented socket_map is closed during the time
between the processing of socket_map and the
select.select call, that call will fail with a Bad File
Descriptor (EBADF) error.

One solution is to patch asyncore to catch EBADF errors
raised by select.select, and at that point see if the
file descriptors in the current version of socket_map 
are the same as in the processed data used for the
select.select call. If they are the same, re-raise the
error, otherwise, ignore the error.

In another email to the Zope 3 developers&#039; list, Jeremy
Hylton queries whether there are any other similar
problems in asyncore.

http://lists.zope.org/pipermail/zope3-dev/2002-October/003093.html


----------------------------------------------------------------------

Comment By: Alexey Klimkin (klimkin)
Date: 2004-02-24 15:03

Message:
Logged In: YES 
user_id=410460

Yup, closing file in separate thread is program's (not
asyncore) error.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-06 01:49

Message:
Logged In: YES 
user_id=6380

According to Jeremy, this is more a matter of "don't do that".

The right solution is to make sure that sockets are only
closed by the main thread (the thread running asyncore.loop()).

I wonder if we should just close this bug report?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629097&group_id=5470

From noreply at sourceforge.net  Tue Feb 24 09:54:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 24 09:56:40 2004
Subject: [ python-Feature Requests-696184 ] Enable __slots__ for meta-types
Message-ID: <E1Avdx9-0006wm-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #696184, was opened at 2003-03-02 21:52
Message generated for change (Settings changed) made by tismer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=696184&group_id=5470

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 2
Submitted By: Christian Tismer (tismer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enable __slots__ for meta-types

Initial Comment:
The new type system allows non-empty __slots__ only
for fixed-size objects.

Meta-types are types which instances are also types.
types are variable-sized, because they take the slot
definitions for their instances, so the cannot have
extra members from their meta-type.

The proposed solution allows for two things:
a) meta-types can have slots
b) extensions get access to the whole type object and
    can create extended types with private fields.

The changes providing this are quite simple:
- replace the internal hidden "etype" and turn it into
  an explicit PyHeapTypeObject in object.h
- instead of a fixed offset into the former etype, the
slots
  calculation is based upon tp_basicsize.

To keep things easy, I added a macro which does this
calculation, and member access read now like so:

before:
	type->tp_members = et->members;
after:
	type->tp_members = PyHeapType_GET_MEMBERS(et);

This patch has been tested thoroughly in my own code since
Python 2.2, and I think it is ripe to get into the
distribution.
It has almost no impact on speed or complexity.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=696184&group_id=5470

From noreply at sourceforge.net  Tue Feb 24 09:59:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 24 10:01:14 2004
Subject: [ python-Feature Requests-903483 ] cPickle/pickle incompatibility
Message-ID: <E1Ave1W-0006zN-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #903483, was opened at 2004-02-24 15:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=903483&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Tismer (tismer)
Assigned to: Christian Tismer (tismer)
Summary: cPickle/pickle incompatibility

Initial Comment:
Pickling of functions:
pickle.py first tries a save_global.
If that doesn&#039;t work, it tries a save_reduce.
This fallback allows to register pickling of local
functions
via copy_reg.

cPickle doesn&#039;t do that.
This bug/omission exists since Python 2.3. 

Solution:
A simple patch allows cPickle to fall back to reduce as
well.

Range:
I think this patch should be applied back to Python 2.3.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=903483&group_id=5470

From noreply at sourceforge.net  Tue Feb 24 10:06:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 24 11:04:22 2004
Subject: [ python-Bugs-903483 ] cPickle/pickle incompatibility
Message-ID: <E1Ave95-00064X-00@sc8-sf-web1.sourceforge.net>

Bugs item #903483, was opened at 2004-02-24 15:59
Message generated for change (Comment added) made by tismer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903483&group_id=5470

Category: Extension Modules
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Christian Tismer (tismer)
>Assigned to: Christian Tismer (tismer)
Summary: cPickle/pickle incompatibility

Initial Comment:
Pickling of functions:
pickle.py first tries a save_global.
If that doesn&#039;t work, it tries a save_reduce.
This fallback allows to register pickling of local
functions
via copy_reg.

cPickle doesn&#039;t do that.
This bug/omission exists since Python 2.3. 

Solution:
A simple patch allows cPickle to fall back to reduce as
well.

Range:
I think this patch should be applied back to Python 2.3.


----------------------------------------------------------------------

>Comment By: Christian Tismer (tismer)
Date: 2004-02-24 16:06

Message:
Logged In: YES 
user_id=105700

Here the obvious patch:

cvs -z9 diff -u -wb cPickle.c (in directory
D:\cvsdown\python\dist\src\Modules\)
Index: cPickle.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/cPickle.c,v
retrieving revision 2.148
diff -u -w -b -r2.148 cPickle.c
--- cPickle.c    12 Oct 2003 19:09:36 -0000    2.148
+++ cPickle.c    24 Feb 2004 14:28:34 -0000
@@ -2418,6 +2418,11 @@
     case 'f':
         if (type == &PyFunction_Type) {
             res = save_global(self, args, NULL);
+            if (res && PyErr_ExceptionMatches(PickleError)) {
+                /* fall back to reduce */
+                       PyErr_Clear();
+                       break;
+            }
             goto finally;
         }
     break;


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903483&group_id=5470

From noreply at sourceforge.net  Tue Feb 24 10:05:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 24 11:04:25 2004
Subject: [ python-Bugs-903483 ] cPickle/pickle incompatibility
Message-ID: <E1Ave7Q-0005wb-00@sc8-sf-web1.sourceforge.net>

Bugs item #903483, was opened at 2004-02-24 15:59
Message generated for change (Settings changed) made by tismer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903483&group_id=5470

>Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Tismer (tismer)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle/pickle incompatibility

Initial Comment:
Pickling of functions:
pickle.py first tries a save_global.
If that doesn&#039;t work, it tries a save_reduce.
This fallback allows to register pickling of local
functions
via copy_reg.

cPickle doesn&#039;t do that.
This bug/omission exists since Python 2.3. 

Solution:
A simple patch allows cPickle to fall back to reduce as
well.

Range:
I think this patch should be applied back to Python 2.3.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903483&group_id=5470

From noreply at sourceforge.net  Tue Feb 24 10:11:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 24 11:04:29 2004
Subject: [ python-Bugs-903483 ] cPickle/pickle incompatibility
Message-ID: <E1AveDc-0006Wm-00@sc8-sf-web1.sourceforge.net>

Bugs item #903483, was opened at 2004-02-24 15:59
Message generated for change (Settings changed) made by tismer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903483&group_id=5470

Category: Extension Modules
>Group: Python 2.3
>Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Tismer (tismer)
Assigned to: Christian Tismer (tismer)
Summary: cPickle/pickle incompatibility

Initial Comment:
Pickling of functions:
pickle.py first tries a save_global.
If that doesn&#039;t work, it tries a save_reduce.
This fallback allows to register pickling of local
functions
via copy_reg.

cPickle doesn&#039;t do that.
This bug/omission exists since Python 2.3. 

Solution:
A simple patch allows cPickle to fall back to reduce as
well.

Range:
I think this patch should be applied back to Python 2.3.


----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2004-02-24 16:06

Message:
Logged In: YES 
user_id=105700

Here the obvious patch:

cvs -z9 diff -u -wb cPickle.c (in directory
D:\cvsdown\python\dist\src\Modules\)
Index: cPickle.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/cPickle.c,v
retrieving revision 2.148
diff -u -w -b -r2.148 cPickle.c
--- cPickle.c    12 Oct 2003 19:09:36 -0000    2.148
+++ cPickle.c    24 Feb 2004 14:28:34 -0000
@@ -2418,6 +2418,11 @@
     case 'f':
         if (type == &PyFunction_Type) {
             res = save_global(self, args, NULL);
+            if (res && PyErr_ExceptionMatches(PickleError)) {
+                /* fall back to reduce */
+                       PyErr_Clear();
+                       break;
+            }
             goto finally;
         }
     break;


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903483&group_id=5470

From noreply at sourceforge.net  Tue Feb 24 10:01:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 24 12:10:56 2004
Subject: [ python-Bugs-903483 ] cPickle/pickle incompatibility
Message-ID: <E1Ave4G-00070q-00@sc8-sf-web3.sourceforge.net>

Bugs item #903483, was opened at 2004-02-24 15:59
Message generated for change (Settings changed) made by tismer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903483&group_id=5470

>Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Tismer (tismer)
>Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle/pickle incompatibility

Initial Comment:
Pickling of functions:
pickle.py first tries a save_global.
If that doesn&#039;t work, it tries a save_reduce.
This fallback allows to register pickling of local
functions
via copy_reg.

cPickle doesn&#039;t do that.
This bug/omission exists since Python 2.3. 

Solution:
A simple patch allows cPickle to fall back to reduce as
well.

Range:
I think this patch should be applied back to Python 2.3.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903483&group_id=5470

From noreply at sourceforge.net  Tue Feb 24 12:16:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 24 12:44:23 2004
Subject: [ python-Bugs-474836 ] Tix not included in windows distribution
Message-ID: <E1AvgAb-0007eS-00@sc8-sf-web1.sourceforge.net>

Bugs item #474836, was opened at 2001-10-25 07:22
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Thomas Heller (theller)
Summary: Tix not included in windows distribution

Initial Comment:
Although there is a Tix.py available, there is no Tix
support in the precomiled 
Python-distribution for windows. So 

import Tix

works fine, but

root = Tix.Tk()

results in 

TclError: package not found. 

It is possible to circumvent this problem by installing
a regular Tcl/Tk distribution (e.g. in
c:\programme\tcl) and installing Tix in the regular
Tcl-path (i.e. tcl\lib).

Mathias

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-02-24 12:16

Message:
Logged In: YES 
user_id=764593

Note that the problem is still there in 2.3.3; if it can't be fixed, 
could the documentation at least mention that Tix requires 
3rd-party libraries on Windows?


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-10-03 09:15

Message:
Logged In: YES 
user_id=21627

Reassigning to Thomas, who is doing Windows releases these days.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-10-03 09:13

Message:
Logged In: YES 
user_id=31435

Unassigned (doesn't look like I'll ever get time for this).

----------------------------------------------------------------------

Comment By: Aaron Optimizer Digulla (digulla)
Date: 2003-10-03 07:10

Message:
Logged In: YES 
user_id=606

loewis, when will your package show up in the official Python 
distribution? It's still not there in 2.3.2 :-(

----------------------------------------------------------------------

Comment By: Aaron Optimizer Digulla (digulla)
Date: 2003-07-28 09:22

Message:
Logged In: YES 
user_id=606

The Tix8184.dll is still missing in Python 2.3c2. The included 
Tix8183.dll (which is in the directory tcl\tix8.1\ along with a 
couple of other dlls -> can't be found by Python) is linked 
against Tcl/Tk 8.3.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-06-15 08:40

Message:
Logged In: YES 
user_id=21627

I found that the instructions need slight modification: In step 
2, use tk...\mkd.bat for mkdir. Apart from that, these 
instructions work fine for me, now. I have made a binary 
release of tix8.1 for Python 2.3 at

http://www.dcl.hpi.uni-potsdam.de/home/loewis/tix8.1.zip

The tix8184.dll goes to DLLs, the tix8.1 subdirectory goes to 
tcl. It differs from the standard tix8.1 subdirectory only in 
fixing the path to the DLLs directory.

To test whether this works, execute Demo/tix/tixwidgets.py.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-04-26 06:22

Message:
Logged In: YES 
user_id=21627

I still think Python should include Tix. Here are some 
instructions on how to make Tix 8.1.4 work:

1. Unpack as a sibling of tcl8.4.1 and tk8.4.1
2. Edit win\common.mk, to set the following variables
    TCL_VER=8.4
    INSTALLDIR=<directory to pick up installation from later>
    MKDIR=mkdir
3. Edit win\makefile.vc, to set the following variables
    TOOLS32=<directory of cl>
    TOOLS32_rc=<directory of rc.exe>
4. Edit win\tk\pkgindex.tcl, to replace
    lappend dirs ../../Dlls
    with
    lappend dirs [file join [file dirname [info nameofexe]] Dlls]
5. nmake -f makefile.vc
6. nmake -f makefile.vc install
7. Copy INSTALLDIR\bin\tix8184.dll to <python>\DLLs
8. Optionally copy tix8184.lib somewhere
9. copy INSTALLDIR\lib\tix8.1 into <python>\tcl

With these instructions, invoking t.tk.eval("package require 
Tix") succeeds. For some reason, Tix won't still find any of 
the commands; I'll investigate this later.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-12-11 04:14

Message:
Logged In: YES 
user_id=33229

My you're courageous - going with a version of Tcl that doesn't
even pass its own tests :-) Been there, seen it, done it ....

8.1.4 will be out this week, which compiles with 8.4 but I don't
expect it to "support" 8.4 for a while yet (they added more problems
in 8.4.1). 8.3.5 is definitely "supported".

Check back with me before 2.3 goes into beta and I'll do
another minor release if necessary. Maybe Tk will test clean then.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-11-19 20:36

Message:
Logged In: YES 
user_id=31435

Parents shouldn't disagree in front of their children <wink>.

Not all the Tcl or Tk tests (their tests, not ours) passed 
when I built 8.4.1, but I couldn't (and can't) make time to 
dig into that, and all the Python stuff I tried worked fine.  So 
I don't fear 8.4, and am inclined to accept Martin's 
assurance that 8.4 is best for Python.

We intend to put out the first 2.3 Python alpha by the end 
of the year, and my bet is it won't be a minute before that.  
If Tix 8.1.4 is at RC3 now, I'd *guess* you'll have a final 
release out well before then.  Yes?  No?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-11-19 17:12

Message:
Logged In: YES 
user_id=21627

I think the recommendation cannot apply to Python; I'm very
much in favour of releasing Python 2.3 with Tk 8.4.x. 

So the question then is whether Python 2.3 should include
Tix 8.1.4 or no Tix at all, and at what time Tix 8.1.4 can
be expected.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-19 14:10

Message:
Logged In: YES 
user_id=33229

Look on http://tix.sourceforge.net/download.shtml for
Tix 8.1.4 RC3. It works with Tk 8.4.1 and passes the test suite,
but there are still issues with Tk 8.4 and it has not been
widely tested with yet with 8.4.1, so we still recommend 8.3.5.
(Tcl major releases often aren't stable until patch .3 or so.)

If you have any problems let me know directly by email
and I'll try and help.








----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-11-18 11:35

Message:
Logged In: YES 
user_id=31435

Does Tix 8.1.3 play with Tcl/Tk 8.4.1?  The 2.3. Windows 
distro is set up to include the latter now.  The 
win\common.mak file from Tix 8.1.3 doesn't have a section 
for Tcl/Tk 8.4, though.

There appear to be several reasons Tix won't compile on 
my box anyway without fiddling the Tix makefiles (e.g., my 
VC doesn't live in \DevStudio), so before spending more 
time on that I'd like to know whether it's doomed.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-07 09:52

Message:
Logged In: YES 
user_id=6380

I support this. Tim, I know you're not a big Tk user (to say
the least). I'll offer to help in person.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-03 02:30

Message:
Logged In: YES 
user_id=33229

I would really like to see Tix in 2.3 and will be glad to help.
AFAIK there are no major issues with tix-8.1.3 and Python 2.x
and it should be a simple drop in of a cannonically compiled Tix.

If there are any issues that need dealing with at Tix's end, I'll be 
glad to put out a new minor release of Tix to address them.

On Python's end I've suggested a fix for http://python.org/sf/564729

FYI, please also see my comments for bug 632323.


----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-03 00:34

Message:
Logged In: YES 
user_id=33229

I would really like to see Tix in 2.3 and will be glad to help.
AFAIK there are no major issues with tix-8.1.3 and Python 2.x
and it should be a simple drop in of a cannonically compiled Tix.

If there are any issues that need dealing with at Tix's end, I'll be 
glad to put out a new minor release of Tix to address them.

On Python's end I've suggested a fix for http://python.org/sf/564729

FYI, please also see my comments for bug 632323.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:34

Message:
Logged In: YES 
user_id=6380

Yes, for 2.3.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 20:48

Message:
Logged In: YES 
user_id=31435

Guido, do you want me to spend time on this?

----------------------------------------------------------------------

Comment By: Mathias Palm (monos)
Date: 2002-03-07 08:38

Message:
Logged In: YES 
user_id=361926

Thanks.

Mathias

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-02-25 07:57

Message:
Logged In: YES 
user_id=21627

The zip file is slightly too large for SF, so it is now at

http://www.informatik.hu-
berlin.de/~loewis/python/tix813win.zip

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-02-25 07:56

Message:
Logged In: YES 
user_id=21627

Building Tix from sources is non-trivial, and I could not 
find any recent Windows binary distribution (based on Tix 
8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, 
as a drop-in into the Python binary distribution.

Compared to the original distribution, only tix8.1
\pkgIndex.tcl required tweaking, to tell it that 
tix8183.dll can be found in the DLLs subdirectory.

Also, unless TIX_LIBRARY is set, the Tix tcl files *must* 
live in tcl\tix8.1, since tix8183.dll will look in 
TCL_LIBRARY\..\tix<TIX_VERSION> (among other locations).

If a major Tcl release happens before Python 2.3 is 
released (and it is then still desirable to distribute 
Python with Tix), these binaries need to be regenerated.

Would these instructions (unpack zip file into 
distribution tree) be precise enough to allow 
incorporation into the windows installer?

----------------------------------------------------------------------

Comment By: Mathias Palm (monos)
Date: 2001-10-29 06:53

Message:
Logged In: YES 
user_id=361926

As mentioned in the mail above (by me, Mathias), Tix is a
package belonging to Tcl/Tk (to be found on sourceforge:
tix.sourceforge.net, or via the Python home page - tkinter
link). 

Everything needed can be found there, just read about it
(and dont forget about the winking,  eyes might be getting
dry)

Mathias



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-25 14:26

Message:
Logged In: YES 
user_id=31435

I don't know anything about Tix, so if somebody wants this 
in the Windows installer, they're going to have to explain 
exactly (by which I mean exactly <0.5 wink>) what's needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470

From noreply at sourceforge.net  Tue Feb 24 17:52:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Feb 24 17:57:43 2004
Subject: [ python-Bugs-902172 ] Timezone miscalculation (time.mktime)
Message-ID: <E1AvlPM-0001ZU-00@sc8-sf-web2.sourceforge.net>

Bugs item #902172, was opened at 2004-02-22 18:09
Message generated for change (Comment added) made by sipsick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902172&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Marti Raudsepp (sipsick)
Assigned to: Brett Cannon (bcannon)
Summary: Timezone miscalculation (time.mktime)

Initial Comment:
The problem:
time.mktime(time.gmtime(0)) - time.timezone == -3600.
0
(Should be 0.0 if I understood it right)

Python seems to miscalculate the local time when using 
mktime. The problem appeared when one of the runtests 
in MoinMoin failed (spefically MoinMoin._tests.
test_parser_wiki.WikiMacroTestCase)

I used two machines for testing:
1. NetBSD 1.6.1 (GENERIC), Python version 2.3.3 (#1, 
Feb 20 2004, 00:53:29) [GCC 2.95.3 20010315 (release) 
(NetBSD nb3)]
2. Linux 2.4.20-3-686 (Debian GNU/Linux), Python 
version 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 
20040110 (prerelease) (Debian)]

Both machine generate the identical error:
AssertionError: Expected &#039;1#1970-01-06 00:00:00#1&#039; in:
1#1970-01-05 23:00:00#1 [...]

A few simple tests in the python shell (both machines)
>>> import time
>>> time.daylight
1
>>> time.timezone
-7200
>>> time.tzname
(&#039;EET&#039;, &#039;EEST&#039;)
>>> time.mktime(time.localtime(0))
0.0
>>> time.mktime(time.gmtime(0)) - time.timezone
-3600.0
>>> time.gmtime(0)
(1970, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.
timezone
-3600.0
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, -1)) - time.
timezone
-3600.0


However, the only difference between the Linux and BSD 
machine is:
1. NetBSD
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-7200.0
2. Linux
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-3600.0

I also attached the results of the moin test just in case.

--
Marti

----------------------------------------------------------------------

>Comment By: Marti Raudsepp (sipsick)
Date: 2004-02-25 00:52

Message:
Logged In: YES 
user_id=345221

Summary: This doesn't look like Python's fault. case closed.

bcannon wrote:
> In other words, EET is two hours ahead of UTC normally and 
only
> one hour ahead during daylight savings).
That is not exactly correct.
EET (Eastern European Time, in winter) is UTC+2h, and
EEST (Eastern European Summer Time) is UTC+3h (This is 
DST)
Reference: http://www.timeanddate.
com/library/abbreviations/timezones/eu/eet.html

The way I understand it, daylight should be 0 not 1. (DST 
hasn't begun yet.
Reference: http://www.timeanddate.com/worldclock/city.html?
n=242

Otherwise you're right: it's not even Python's fault! I got 
exactly the same results on my Linux machine when I tested it 
in C. So I suppose this case is closed.
struct tm format: {sec, min, hour, mday, mon, year, wday, 
yday, isdst}

daylight = 1
timezone = -7200
tzname = {"EET", "EEST"}
mktime(localtime(0)) = 0
mktime(gmtime(0)) - timezone = -3600
gmtime(0) = {0, 0, 0, 1, 0, 70, 4, 0, 0}
mktime({0, 0, 0, 1, 0, 70, 4, 0, 0}) - timezone = -3600
mktime({0, 0, 0, 1, 0, 70, 4, 0,-1}) - timezone = -3600
mktime({0, 0, 0, 1, 0, 70, 4, 0, 1}) - timezone = -3600

I attached the code of mktime.c just in case anybody would 
want to review it.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-02-24 10:36

Message:
Logged In: YES 
user_id=357491

OK, what I need is the result for ``time.localtime(0)`` (according to the 
calculations above should be three hours ahead of UTC, but in actuality, 
as long as the DST field is 0, should only be two hours ahead for EET) 
and ``time.mktime(time.gmtime(0))`` (should be -10800 according to 
the calculations above, but I want to double-check).  And the value of 
``time.altzone`` wouldn't hurt for trying to deal with the slight 
difference between the two OSs (should be -3600, or 1 hour ahead of 
UTC, for DST in EET, right?  In other words, EET is two hours ahead of 
UTC normally and only one hour ahead during daylight savings).

It looks like time.localtime(0) is off by an hour for some odd reason.  
And as for the discrepency between platforms, it should be only an hour 
difference since you should be subtracting time.altzone with the DST flag 
set to 1 and not time.timezone .  So it looks like Linux is behaving 
correctly and NetBSD is being really screwy if that is the only difference 
between the platforms.

But, to be honest, from a quick glance and the code, the wrappers are so 
thin that I don't think it is going to be on our side.  But with the info 
above I should be able to figure out where the discrepency is coming 
from and be able to make sure whose fault it is.

----------------------------------------------------------------------

Comment By: Marti Raudsepp (sipsick)
Date: 2004-02-22 18:11

Message:
Logged In: YES 
user_id=345221

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

Comment By: Marti Raudsepp (sipsick)
Date: 2004-02-22 18:11

Message:
Logged In: YES 
user_id=345221

Oops, forgot to check the upload box :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902172&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 02:06:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 02:08:48 2004
Subject: [ python-Bugs-743267 ] super passes bad arguments to __get__ when
	used w/class
Message-ID: <E1Avt7f-00042t-00@sc8-sf-web2.sourceforge.net>

Bugs item #743267, was opened at 2003-05-25 18:00
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: super passes bad arguments to __get__ when used w/class

Initial Comment:
Run the following code to demonstrate the issue:

====
class Getter(object):
    def __get__(self, ob, typ=None):
        print "called with", (ob, typ)

class Base(object):
    foo = Getter()

class Subclass(Base):
    pass

print
print

Base().foo
Subclass().foo
super(Subclass,Subclass()).foo

Base.foo
Subclass.foo
super(Subclass,Subclass).foo
====

Notice that super(Subclass,Subclass).foo is calling the
descriptor with the *class* object, not &#039;None&#039; as is
done for the analagous cases that don&#039;t use super().

The only reason this ever "works" is because
&#039;classmethod&#039; ignores the &#039;ob&#039; parameter to &#039;__get__&#039;.
 However, this breaks when using &#039;super&#039; to access
property descriptors in 2.3, and it will also break any
user-defined descriptors that are accessed via super().

The behavior is the same in 2.2, and is arguably broken
there as well.  For example,
&#039;super(someclass,someclass).X&#039; (where &#039;X&#039; is a normal
instance method) results in X being a *bound* method,
bound to the class, rather than an *unbound* method,
ready for use with an explicit instance.

Personally, I would be happy if super() grew an extra
argument to disambiguate whether you are doing a
(class,instance) or (class,class) call, anyway.  When
using super() with metaclasses, I&#039;ve encountered
situations where super() guessed wrong, because I was
using a type that was both an instance of, and a
subclass of, the same type.  Being able to explicitly
request that this "class method" form of super is being
used, would eliminate this confusion as well.  In the
face of ambiguity... ;)


----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 07:06

Message:
Logged In: YES 
user_id=56214

Assigning to Guido to request pronouncement on the correct
way to fix this before I attempt to create patch(es).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 10:57:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 10:59:20 2004
Subject: [ python-Bugs-743267 ] super passes bad arguments to __get__ when
	used w/class
Message-ID: <E1Aw1PB-0007Nk-00@sc8-sf-web4.sourceforge.net>

Bugs item #743267, was opened at 2003-05-25 14:00
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Guido van Rossum (gvanrossum)
Summary: super passes bad arguments to __get__ when used w/class

Initial Comment:
Run the following code to demonstrate the issue:

====
class Getter(object):
    def __get__(self, ob, typ=None):
        print "called with", (ob, typ)

class Base(object):
    foo = Getter()

class Subclass(Base):
    pass

print
print

Base().foo
Subclass().foo
super(Subclass,Subclass()).foo

Base.foo
Subclass.foo
super(Subclass,Subclass).foo
====

Notice that super(Subclass,Subclass).foo is calling the
descriptor with the *class* object, not &#039;None&#039; as is
done for the analagous cases that don&#039;t use super().

The only reason this ever "works" is because
&#039;classmethod&#039; ignores the &#039;ob&#039; parameter to &#039;__get__&#039;.
 However, this breaks when using &#039;super&#039; to access
property descriptors in 2.3, and it will also break any
user-defined descriptors that are accessed via super().

The behavior is the same in 2.2, and is arguably broken
there as well.  For example,
&#039;super(someclass,someclass).X&#039; (where &#039;X&#039; is a normal
instance method) results in X being a *bound* method,
bound to the class, rather than an *unbound* method,
ready for use with an explicit instance.

Personally, I would be happy if super() grew an extra
argument to disambiguate whether you are doing a
(class,instance) or (class,class) call, anyway.  When
using super() with metaclasses, I&#039;ve encountered
situations where super() guessed wrong, because I was
using a type that was both an instance of, and a
subclass of, the same type.  Being able to explicitly
request that this "class method" form of super is being
used, would eliminate this confusion as well.  In the
face of ambiguity... ;)


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-02-25 10:57

Message:
Logged In: YES 
user_id=6380

> However, this breaks when using &#039;super&#039; to access
> property descriptors in 2.3, and it will also break any
> user-defined descriptors that are accessed via super().

Can you give an example of this use case?

I don't have a strong opinion on this; methinks you should
go ahead and prepa patch...

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 02:06

Message:
Logged In: YES 
user_id=56214

Assigning to Guido to request pronouncement on the correct
way to fix this before I attempt to create patch(es).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 14:06:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 14:08:53 2004
Subject: [ python-Bugs-743267 ] super passes bad arguments to __get__ when
	used w/class
Message-ID: <E1Aw4Me-0008U9-00@sc8-sf-web3.sourceforge.net>

Bugs item #743267, was opened at 2003-05-25 18:00
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Guido van Rossum (gvanrossum)
Summary: super passes bad arguments to __get__ when used w/class

Initial Comment:
Run the following code to demonstrate the issue:

====
class Getter(object):
    def __get__(self, ob, typ=None):
        print "called with", (ob, typ)

class Base(object):
    foo = Getter()

class Subclass(Base):
    pass

print
print

Base().foo
Subclass().foo
super(Subclass,Subclass()).foo

Base.foo
Subclass.foo
super(Subclass,Subclass).foo
====

Notice that super(Subclass,Subclass).foo is calling the
descriptor with the *class* object, not &#039;None&#039; as is
done for the analagous cases that don&#039;t use super().

The only reason this ever "works" is because
&#039;classmethod&#039; ignores the &#039;ob&#039; parameter to &#039;__get__&#039;.
 However, this breaks when using &#039;super&#039; to access
property descriptors in 2.3, and it will also break any
user-defined descriptors that are accessed via super().

The behavior is the same in 2.2, and is arguably broken
there as well.  For example,
&#039;super(someclass,someclass).X&#039; (where &#039;X&#039; is a normal
instance method) results in X being a *bound* method,
bound to the class, rather than an *unbound* method,
ready for use with an explicit instance.

Personally, I would be happy if super() grew an extra
argument to disambiguate whether you are doing a
(class,instance) or (class,class) call, anyway.  When
using super() with metaclasses, I&#039;ve encountered
situations where super() guessed wrong, because I was
using a type that was both an instance of, and a
subclass of, the same type.  Being able to explicitly
request that this "class method" form of super is being
used, would eliminate this confusion as well.  In the
face of ambiguity... ;)


----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 19:06

Message:
Logged In: YES 
user_id=56214

super().descriptor example:

class Base(object):
    aProp = property(lambda self: "foo")

class Sub(Base):
    def test(klass):
        print super(Sub,klass).aProp
    test = classmethod(test)

Sub.test()

This prints "foo", when it should print "<property object at
0x4024f84c>" instead.

To be precise, the issue is that accessing any descriptor
that behaves differently when retrieved on the class vs. the
instance, will behave incorrectly when accessed via super()
from a classmethod in a subclass.  Classmethods themselves
work correctly because they behave the same way no matter
how you retrieve them.

At present I think the patch should simply change the
descr_get call in super_getattro so that it checks whether
su->obj==su->obj_type, and if so, pass in NULL instead of
su->obj as the second argument to descr_get.

Should I create this patch against the 2.3 maintenance
branch, or against the head?  I'd like to make sure it gets
into the next 2.3.x bugfix release.  (I didn't realize this
bug was still open until I stumbled across it the other day,
and I'm not expecting to upgrade to 2.3 production use for a
few months yet.  I've been using a pure-Python
reimplementation of super() as a workaround.)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-02-25 15:57

Message:
Logged In: YES 
user_id=6380

> However, this breaks when using &#039;super&#039; to access
> property descriptors in 2.3, and it will also break any
> user-defined descriptors that are accessed via super().

Can you give an example of this use case?

I don't have a strong opinion on this; methinks you should
go ahead and prepa patch...

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 07:06

Message:
Logged In: YES 
user_id=56214

Assigning to Guido to request pronouncement on the correct
way to fix this before I attempt to create patch(es).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 14:09:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 14:11:42 2004
Subject: [ python-Bugs-743267 ] super passes bad arguments to __get__ when
	used w/class
Message-ID: <E1Aw4PS-0000Es-00@sc8-sf-web3.sourceforge.net>

Bugs item #743267, was opened at 2003-05-25 19:00
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Guido van Rossum (gvanrossum)
Summary: super passes bad arguments to __get__ when used w/class

Initial Comment:
Run the following code to demonstrate the issue:

====
class Getter(object):
    def __get__(self, ob, typ=None):
        print "called with", (ob, typ)

class Base(object):
    foo = Getter()

class Subclass(Base):
    pass

print
print

Base().foo
Subclass().foo
super(Subclass,Subclass()).foo

Base.foo
Subclass.foo
super(Subclass,Subclass).foo
====

Notice that super(Subclass,Subclass).foo is calling the
descriptor with the *class* object, not &#039;None&#039; as is
done for the analagous cases that don&#039;t use super().

The only reason this ever "works" is because
&#039;classmethod&#039; ignores the &#039;ob&#039; parameter to &#039;__get__&#039;.
 However, this breaks when using &#039;super&#039; to access
property descriptors in 2.3, and it will also break any
user-defined descriptors that are accessed via super().

The behavior is the same in 2.2, and is arguably broken
there as well.  For example,
&#039;super(someclass,someclass).X&#039; (where &#039;X&#039; is a normal
instance method) results in X being a *bound* method,
bound to the class, rather than an *unbound* method,
ready for use with an explicit instance.

Personally, I would be happy if super() grew an extra
argument to disambiguate whether you are doing a
(class,instance) or (class,class) call, anyway.  When
using super() with metaclasses, I&#039;ve encountered
situations where super() guessed wrong, because I was
using a type that was both an instance of, and a
subclass of, the same type.  Being able to explicitly
request that this "class method" form of super is being
used, would eliminate this confusion as well.  In the
face of ambiguity... ;)


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-02-25 19:09

Message:
Logged In: YES 
user_id=6656

I don't think you'll find any difference between the trunk
and release23-maint in this area, so it doesn't make much
difference.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 19:06

Message:
Logged In: YES 
user_id=56214

super().descriptor example:

class Base(object):
    aProp = property(lambda self: "foo")

class Sub(Base):
    def test(klass):
        print super(Sub,klass).aProp
    test = classmethod(test)

Sub.test()

This prints "foo", when it should print "<property object at
0x4024f84c>" instead.

To be precise, the issue is that accessing any descriptor
that behaves differently when retrieved on the class vs. the
instance, will behave incorrectly when accessed via super()
from a classmethod in a subclass.  Classmethods themselves
work correctly because they behave the same way no matter
how you retrieve them.

At present I think the patch should simply change the
descr_get call in super_getattro so that it checks whether
su->obj==su->obj_type, and if so, pass in NULL instead of
su->obj as the second argument to descr_get.

Should I create this patch against the 2.3 maintenance
branch, or against the head?  I'd like to make sure it gets
into the next 2.3.x bugfix release.  (I didn't realize this
bug was still open until I stumbled across it the other day,
and I'm not expecting to upgrade to 2.3 production use for a
few months yet.  I've been using a pure-Python
reimplementation of super() as a workaround.)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-02-25 15:57

Message:
Logged In: YES 
user_id=6380

> However, this breaks when using &#039;super&#039; to access
> property descriptors in 2.3, and it will also break any
> user-defined descriptors that are accessed via super().

Can you give an example of this use case?

I don't have a strong opinion on this; methinks you should
go ahead and prepa patch...

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 07:06

Message:
Logged In: YES 
user_id=56214

Assigning to Guido to request pronouncement on the correct
way to fix this before I attempt to create patch(es).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 14:14:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 14:16:41 2004
Subject: [ python-Bugs-848871 ] Windows installer halts
Message-ID: <E1Aw4UA-00014G-00@sc8-sf-web1.sourceforge.net>

Bugs item #848871, was opened at 2003-11-25 12:38
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848871&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jens Olsson (morr)
Assigned to: Thomas Heller (theller)
Summary: Windows installer halts

Initial Comment:
The Windows installer halts when starting to install files, 
more exactly when installing the file "UNWISE.EXE" and 
the progress bar reads "1%".

Python versions tested:
2.2.3
2.3.1
2.3.2
2.3.2-1

All tested versions behave the same. Since I don&#039;t believe 
it&#039;s a common bug I attach selected computer specs for 
the system in question. I find it hard to believe it is the 
python windows installer by itself that contains the bug 
but since I haven&#039;t experienced this with any other 
installer I submit the bug anyway. It can&#039;t be my system 
by itself either.

- Varying the installation options does not seem to help 
(non exhaustive testing done).
- Running install on on specific processor (Hyper 
Threading is enabled) does not change things

Test system summary (see attachment for full specs):
Gigabyte 8KNXP motherboard, intel Northwood 3.0GHz HT, 
2x512MB Corsair 3500, Radeon 9700 AIW, Seagate 
Barracuda 160GB, Windows XP Pro SP1a.

Reproduction steps:
1. Launch installer
2. Click &#039;next&#039; when asked for directory
3. Click &#039;next&#039; when asked about backups
4. Click &#039;next&#039; when asked for component selection
5. Click &#039;next&#039; when asked for start menu group selection
6. Click &#039;next&#039; when prompted with the "ready to install" 
screen
7. Observere bug


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-02-25 20:14

Message:
Logged In: YES 
user_id=11105

Nope, there isn't really progress.  I spend some time in the
wise support news group, but didn't really get a useful
answer.  I have to limit the time I spend on this.

IMO a better thing would be to bring the innosetup script in
CVS up to date with the current inno version - they are at
4.1.x currently, and add code for the missing features.  I
have the impression that innosetup is powerful enough to
handle all that is needed.

The only downside would that probably Python 2.3.4 will be
the only version using this installer, since 2.4 will be
released as MSI file.

----------------------------------------------------------------------

Comment By: Jens Olsson (morr)
Date: 2004-02-24 10:29

Message:
Logged In: YES 
user_id=917179

Any news on this one? Latest version behaves the same. Is 
there any alternative Windows install procedure that is 
reasonable easy to perform?

----------------------------------------------------------------------

Comment By: Jens Olsson (morr)
Date: 2003-12-10 12:38

Message:
Logged In: YES 
user_id=917179

I couldn't update comments and didn't have time to figure out 
how I should do it so I hope this attached file will do.

Follow up:

I ran the installer with the suggested /m1 option. The install 
asked for the following directories (in order):

windows 
system
system32
temp
source

All input boxes had default values which seemed reasonable so 
I left them unchanged.

Then the actual installer window showed (as without /m1). 
After submitting the requested information (as reported in the 
inital bugreport) the installer halted when the small window 
titled "installing" showed, at 1% and the file unwise.exe... just 
as before. No question about registring files (besides the five 
windows promting for manual input of directories as described 
above).

No error messages. Just the same behaviour as before with 
some additional directory prompting dialoges at the beginning.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-12-05 20:49

Message:
Logged In: YES 
user_id=11105

Here is advice I got from a Wise rep:

"""
This sounds like it is hanging at the point that the install
is trying to self register files. You can test this by
running the setup.exe with a /m1.  This will run the install
in manual mode, and prompt when each file is trying to self
register.  This will indicate which file it is trying to
self register, and then the error message.
"""

Can you try this, please, and report the result?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2003-12-03 21:58

Message:
Logged In: YES 
user_id=11105

I've asked in the WISE support news group for help, I've
also seen similar behaviour in other software built with WISE.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848871&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 14:30:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 14:32:54 2004
Subject: [ python-Bugs-904474 ] File read of Chinese utf-16-le treats upper
	byte 1A as EOF
Message-ID: <E1Aw4jy-0001XA-00@sc8-sf-web3.sourceforge.net>

Bugs item #904474, was opened at 2004-02-25 13:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904474&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ron Rother (rrother)
Assigned to: Nobody/Anonymous (nobody)
Summary: File read of Chinese utf-16-le treats upper byte 1A as EOF

Initial Comment:
Any utf-16-le Chinese character with 1A as the most 
significant byte causes remainder of file to be ignored.

code extract:

(utf16_encoder, utf16_decoder, utf16_reader, 
utf16_writer) = codecs.lookup("utf-16-le")

ifile = utf16_reader(open(sys.argv[1],"r"))

t=ifile.read()

When the Chinese character 1A 5C (&#23578;) is encoundered, 
everthing from the 5C is discarded.

These 3 lines:
English="You have not selected any books!"
Context=1,[MsgBox "You have not selected any books!"]
Chinese(Simplified)="&#23578;&#26410;&#36873;&#25321;&#20219;&#20309;&#20070;&#21367;&#65281;"

are input as:
English="You have not selected any books!"
Context=1,[MsgBox "You have not selected any books!"]
Chinese(Simplified)="

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904474&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 14:53:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 14:56:24 2004
Subject: [ python-Bugs-889200 ] bundlebuilder standalone app doesn't fully
	quit
Message-ID: <E1Aw56S-0003V5-00@sc8-sf-web1.sourceforge.net>

Bugs item #889200, was opened at 2004-02-02 10:08
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder standalone app doesn't fully quit

Initial Comment:
I used bundlebuilder to create a fully standalone app (well, it fails on Jaguar, alas, but the python framework is inside the app). It works fine, but when I quit the app and try to delete it I get the following message from Finder and the item "python" in the .app is not deleted:

The operation cannot be completed because the item "Python" is in use.

The only way I&#039;ve found to delete the app is to REBOOT. Simply logging out and in again does not do the job (which I find quite startling).

I worked around the problem by making the app semi_standalone, but would rather have it fully self-contained 

It&#039;s a huge app; I&#039;ve not tried to break it down, but some things to consider:
- it uses networking (though I need not make a connection to cause this problem)
- it uses Tkinter (and yes the Tcl and Tk frameworks were installed in the app along with the Python framework)
- it uses a few threads for networking (again, though, the problem occurs even if no connection is ever made, suggesting that no threads have to be started to cause the problem)


-- Russell

I have attached the two code files I use to build the application (combined in one zip archive).

----------------------------------------------------------------------

>Comment By: Russell Owen (reowen)
Date: 2004-02-25 11:53

Message:
Logged In: YES 
user_id=431773

I build the applications on Panther (10.3.2 with all but the 2004-02-23 security patch installed).

I checked ps -x before running the app and then again after I did all this: ran, quit and trashed the app and (unsuccessfully, as per the bug report) to empty the trash. Unfortunately there was NO change (aside from CPU time) in the ps -x listing from before to after -- same PIDs and names (and of course the same # of processes). I saved the output in case anyone wants a copy. I only checked by eye so I might have missed something very subtle, but I doubt it.

Any other tests you can think of? I'm really puzzled.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-12 20:55

Message:
Logged In: YES 
user_id=139309

Was the standalone bundle created on Jaguar or Panther?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-02-06 15:17

Message:
Logged In: YES 
user_id=45365

Russell,
could you try using "ps" (probably "ps -x", both before running the .app 
and after running it) to check that the application has indeed fully exited? 
The fact that you mention there are multiple threads somehow suggests 
that there is something still using that Python...

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-02 10:10

Message:
Logged In: YES 
user_id=431773

Note: the included BuildMacTUI.py uses semi_standalone = True, but the problem only occurs if I use standalone = True instead. Sorry for the potential confusion.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 15:00:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 15:03:06 2004
Subject: [ python-Bugs-904498 ] threading docs,
	start error should be specified
Message-ID: <E1Aw5D1-0005n7-00@sc8-sf-web2.sourceforge.net>

Bugs item #904498, was opened at 2004-02-25 12:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904498&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading docs, start error should be specified

Initial Comment:
The docs say it is an error to start a threading thread more than once, but they do not specify exactly what exception will be raised.

Apparently it is always AssertionError (though an expert should verify this).

It would be very helpful to document the exception because there is no other documented way to tell if a threading thread has been started than to try to start it.

I posted to the dev group on 2003-02-24 about this and Aahz asked me to file a doc bug. So here it is.

I suggest the info go in the Thread object docs, in the documentation for "start".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904498&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 15:26:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 15:29:12 2004
Subject: [ python-Bugs-889200 ] bundlebuilder standalone app doesn't fully
	quit
Message-ID: <E1Aw5cO-0004im-00@sc8-sf-web3.sourceforge.net>

Bugs item #889200, was opened at 2004-02-02 19:08
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder standalone app doesn't fully quit

Initial Comment:
I used bundlebuilder to create a fully standalone app (well, it fails on Jaguar, alas, but the python framework is inside the app). It works fine, but when I quit the app and try to delete it I get the following message from Finder and the item "python" in the .app is not deleted:

The operation cannot be completed because the item "Python" is in use.

The only way I&#039;ve found to delete the app is to REBOOT. Simply logging out and in again does not do the job (which I find quite startling).

I worked around the problem by making the app semi_standalone, but would rather have it fully self-contained 

It&#039;s a huge app; I&#039;ve not tried to break it down, but some things to consider:
- it uses networking (though I need not make a connection to cause this problem)
- it uses Tkinter (and yes the Tcl and Tk frameworks were installed in the app along with the Python framework)
- it uses a few threads for networking (again, though, the problem occurs even if no connection is ever made, suggesting that no threads have to be started to cause the problem)


-- Russell

I have attached the two code files I use to build the application (combined in one zip archive).

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2004-02-25 21:26

Message:
Logged In: YES 
user_id=45365

Hmm. Let's first try and find out what else can be meant by "in use". It is 
probably either a filesystem-related thing or a process/framework-
related thing.

First: could you check both the console log file and the system log file 
(both with Utilities->Console) for any clues? Probably best to open both, 
then run the app, then try to delete it, and see whether anything shows 
up.

Next thing to try is good old unix "rm -r" on the app. Does that work or 
not?

If rm -r works then I think I would proceed by "rm -r"ing specific parts of 
the app, and see whether there's any part that, when removed, will 
make empty trash continue. 

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-25 20:53

Message:
Logged In: YES 
user_id=431773

I build the applications on Panther (10.3.2 with all but the 2004-02-23 security patch installed).

I checked ps -x before running the app and then again after I did all this: ran, quit and trashed the app and (unsuccessfully, as per the bug report) to empty the trash. Unfortunately there was NO change (aside from CPU time) in the ps -x listing from before to after -- same PIDs and names (and of course the same # of processes). I saved the output in case anyone wants a copy. I only checked by eye so I might have missed something very subtle, but I doubt it.

Any other tests you can think of? I'm really puzzled.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-13 05:55

Message:
Logged In: YES 
user_id=139309

Was the standalone bundle created on Jaguar or Panther?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-02-07 00:17

Message:
Logged In: YES 
user_id=45365

Russell,
could you try using "ps" (probably "ps -x", both before running the .app 
and after running it) to check that the application has indeed fully exited? 
The fact that you mention there are multiple threads somehow suggests 
that there is something still using that Python...

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-02 19:10

Message:
Logged In: YES 
user_id=431773

Note: the included BuildMacTUI.py uses semi_standalone = True, but the problem only occurs if I use standalone = True instead. Sorry for the potential confusion.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 15:38:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 15:41:01 2004
Subject: [ python-Bugs-808164 ] socket.close() doesn't play well with __del__
Message-ID: <E1Aw5np-0005J6-00@sc8-sf-web3.sourceforge.net>

Bugs item #808164, was opened at 2003-09-17 16:16
Message generated for change (Comment added) made by jbrouwers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808164&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Perry Greenfield (perrygreenfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.close() doesn't play well with __del__

Initial Comment:
It appears that 2.3 changed how socket.close() works. 
We now find errors when terminating Python when we 
reference socket.close() in a __del__ method. We have 
worked around it by removing calls to socket.close() but 
note the following differences between the same section 
of code between 2.2 and 2.3 which suggest that the 2.3 
behavior is not ideal and should be fixed.

In Python 2.3:

    def close(self):
        self._sock = _closedsocket()
        self.send = self.recv = self.sendto = self.recvfrom                         = self._sock._dummy

In Python 2.2:

    def close(self):
        # Avoid referencing globals here
        self._sock = self.__class__._closedsocket()

Note the reference to avoiding globals which is 
presumably the source of the problem with 2.3. Perhaps 
I&#039;m naive but I would guess that calling a close method 
should be considered a safe operation for use in a 
__del__ method.

----------------------------------------------------------------------

Comment By: Jean M. Brouwers (jbrouwers)
Date: 2004-02-25 14:38

Message:
Logged In: YES 
user_id=832557

Two other comments on socket.close() in Python 2.3.

In addition, the socket.close() method in the Lib/socket.py
class does not even call the _realsocket.close() method.

Before zapping the _sock attribute, shouldn't the latter
close() method be called first?  If not, what happens to
any data which may be buffered by the _realsocket?


Also, every time the socket.close() method is called
another, new instance of the _closedsocket class is
created.  That seems unnecessary waste.

Why not use a single instance created once at the
module level?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808164&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 17:33:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 17:36:16 2004
Subject: [ python-Bugs-889200 ] bundlebuilder standalone app doesn't fully
	quit
Message-ID: <E1Aw7ad-00065H-00@sc8-sf-web2.sourceforge.net>

Bugs item #889200, was opened at 2004-02-02 10:08
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder standalone app doesn't fully quit

Initial Comment:
I used bundlebuilder to create a fully standalone app (well, it fails on Jaguar, alas, but the python framework is inside the app). It works fine, but when I quit the app and try to delete it I get the following message from Finder and the item "python" in the .app is not deleted:

The operation cannot be completed because the item "Python" is in use.

The only way I&#039;ve found to delete the app is to REBOOT. Simply logging out and in again does not do the job (which I find quite startling).

I worked around the problem by making the app semi_standalone, but would rather have it fully self-contained 

It&#039;s a huge app; I&#039;ve not tried to break it down, but some things to consider:
- it uses networking (though I need not make a connection to cause this problem)
- it uses Tkinter (and yes the Tcl and Tk frameworks were installed in the app along with the Python framework)
- it uses a few threads for networking (again, though, the problem occurs even if no connection is ever made, suggesting that no threads have to be started to cause the problem)


-- Russell

I have attached the two code files I use to build the application (combined in one zip archive).

----------------------------------------------------------------------

>Comment By: Russell Owen (reowen)
Date: 2004-02-25 14:33

Message:
Logged In: YES 
user_id=431773

First of all, after trying to empty the trash (and saying "Continue" when it complains that Python is in use), all that is left of the application bundle is:
Contents/Frameworks/Python.framework/Versions/2.3/Python

I opened the system.log and console.log and watched while I started and stopped the application and then deleted as much of it as I could. Absolutely nothing showed up in system.log. The console showed: "running sitecustomize.py" as usual on startup and then 0 (the digit zero) on quit. No messages during the partial emptying of trash.

Next I tried rm -R. It did empty the trash. I hope it doesn't cause any problems (nothing so far, but I just did it a minute ago).

Any other ideas? (Trying rm on a specific file seems sort of pointless because I think I already know which single file is tied up.)

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-02-25 12:26

Message:
Logged In: YES 
user_id=45365

Hmm. Let's first try and find out what else can be meant by "in use". It is 
probably either a filesystem-related thing or a process/framework-
related thing.

First: could you check both the console log file and the system log file 
(both with Utilities->Console) for any clues? Probably best to open both, 
then run the app, then try to delete it, and see whether anything shows 
up.

Next thing to try is good old unix "rm -r" on the app. Does that work or 
not?

If rm -r works then I think I would proceed by "rm -r"ing specific parts of 
the app, and see whether there's any part that, when removed, will 
make empty trash continue. 

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-25 11:53

Message:
Logged In: YES 
user_id=431773

I build the applications on Panther (10.3.2 with all but the 2004-02-23 security patch installed).

I checked ps -x before running the app and then again after I did all this: ran, quit and trashed the app and (unsuccessfully, as per the bug report) to empty the trash. Unfortunately there was NO change (aside from CPU time) in the ps -x listing from before to after -- same PIDs and names (and of course the same # of processes). I saved the output in case anyone wants a copy. I only checked by eye so I might have missed something very subtle, but I doubt it.

Any other tests you can think of? I'm really puzzled.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-12 20:55

Message:
Logged In: YES 
user_id=139309

Was the standalone bundle created on Jaguar or Panther?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-02-06 15:17

Message:
Logged In: YES 
user_id=45365

Russell,
could you try using "ps" (probably "ps -x", both before running the .app 
and after running it) to check that the application has indeed fully exited? 
The fact that you mention there are multiple threads somehow suggests 
that there is something still using that Python...

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-02 10:10

Message:
Logged In: YES 
user_id=431773

Note: the included BuildMacTUI.py uses semi_standalone = True, but the problem only occurs if I use standalone = True instead. Sorry for the potential confusion.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 17:40:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 17:42:38 2004
Subject: [ python-Bugs-889200 ] bundlebuilder standalone app doesn't fully
	quit
Message-ID: <E1Aw7hO-0005UP-00@sc8-sf-web4.sourceforge.net>

Bugs item #889200, was opened at 2004-02-02 13:08
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder standalone app doesn't fully quit

Initial Comment:
I used bundlebuilder to create a fully standalone app (well, it fails on Jaguar, alas, but the python framework is inside the app). It works fine, but when I quit the app and try to delete it I get the following message from Finder and the item "python" in the .app is not deleted:

The operation cannot be completed because the item "Python" is in use.

The only way I&#039;ve found to delete the app is to REBOOT. Simply logging out and in again does not do the job (which I find quite startling).

I worked around the problem by making the app semi_standalone, but would rather have it fully self-contained 

It&#039;s a huge app; I&#039;ve not tried to break it down, but some things to consider:
- it uses networking (though I need not make a connection to cause this problem)
- it uses Tkinter (and yes the Tcl and Tk frameworks were installed in the app along with the Python framework)
- it uses a few threads for networking (again, though, the problem occurs even if no connection is ever made, suggesting that no threads have to be started to cause the problem)


-- Russell

I have attached the two code files I use to build the application (combined in one zip archive).

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 17:40

Message:
Logged In: YES 
user_id=139309

I would like to see the output of "ls -l" and "otool -L" on that file..

This is a Python framework build built by yourself, correct?  If you are 
running --standalone w/ a "/System" Python then you are not really 
doing anything useful (or supported, etc.) in the first place.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-25 17:33

Message:
Logged In: YES 
user_id=431773

First of all, after trying to empty the trash (and saying "Continue" when it complains that Python is in use), all that is left of the application bundle is:
Contents/Frameworks/Python.framework/Versions/2.3/Python

I opened the system.log and console.log and watched while I started and stopped the application and then deleted as much of it as I could. Absolutely nothing showed up in system.log. The console showed: "running sitecustomize.py" as usual on startup and then 0 (the digit zero) on quit. No messages during the partial emptying of trash.

Next I tried rm -R. It did empty the trash. I hope it doesn't cause any problems (nothing so far, but I just did it a minute ago).

Any other ideas? (Trying rm on a specific file seems sort of pointless because I think I already know which single file is tied up.)

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-02-25 15:26

Message:
Logged In: YES 
user_id=45365

Hmm. Let's first try and find out what else can be meant by "in use". It is 
probably either a filesystem-related thing or a process/framework-
related thing.

First: could you check both the console log file and the system log file 
(both with Utilities->Console) for any clues? Probably best to open both, 
then run the app, then try to delete it, and see whether anything shows 
up.

Next thing to try is good old unix "rm -r" on the app. Does that work or 
not?

If rm -r works then I think I would proceed by "rm -r"ing specific parts of 
the app, and see whether there's any part that, when removed, will 
make empty trash continue. 

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-25 14:53

Message:
Logged In: YES 
user_id=431773

I build the applications on Panther (10.3.2 with all but the 2004-02-23 security patch installed).

I checked ps -x before running the app and then again after I did all this: ran, quit and trashed the app and (unsuccessfully, as per the bug report) to empty the trash. Unfortunately there was NO change (aside from CPU time) in the ps -x listing from before to after -- same PIDs and names (and of course the same # of processes). I saved the output in case anyone wants a copy. I only checked by eye so I might have missed something very subtle, but I doubt it.

Any other tests you can think of? I'm really puzzled.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-12 23:55

Message:
Logged In: YES 
user_id=139309

Was the standalone bundle created on Jaguar or Panther?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-02-06 18:17

Message:
Logged In: YES 
user_id=45365

Russell,
could you try using "ps" (probably "ps -x", both before running the .app 
and after running it) to check that the application has indeed fully exited? 
The fact that you mention there are multiple threads somehow suggests 
that there is something still using that Python...

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-02 13:10

Message:
Logged In: YES 
user_id=431773

Note: the included BuildMacTUI.py uses semi_standalone = True, but the problem only occurs if I use standalone = True instead. Sorry for the potential confusion.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 17:53:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 17:56:07 2004
Subject: [ python-Bugs-904474 ] File read of Chinese utf-16-le treats upper
	byte 1A as EOF
Message-ID: <E1Aw7uU-0005Ws-00@sc8-sf-web1.sourceforge.net>

Bugs item #904474, was opened at 2004-02-25 20:30
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904474&group_id=5470

>Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ron Rother (rrother)
Assigned to: Nobody/Anonymous (nobody)
Summary: File read of Chinese utf-16-le treats upper byte 1A as EOF

Initial Comment:
Any utf-16-le Chinese character with 1A as the most 
significant byte causes remainder of file to be ignored.

code extract:

(utf16_encoder, utf16_decoder, utf16_reader, 
utf16_writer) = codecs.lookup("utf-16-le")

ifile = utf16_reader(open(sys.argv[1],"r"))

t=ifile.read()

When the Chinese character 1A 5C (&#23578;) is encoundered, 
everthing from the 5C is discarded.

These 3 lines:
English="You have not selected any books!"
Context=1,[MsgBox "You have not selected any books!"]
Chinese(Simplified)="&#23578;&#26410;&#36873;&#25321;&#20219;&#20309;&#20070;&#21367;&#65281;"

are input as:
English="You have not selected any books!"
Context=1,[MsgBox "You have not selected any books!"]
Chinese(Simplified)="

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-25 23:53

Message:
Logged In: YES 
user_id=38388

I believe there is a misconception here: the open(..., "r")
will cause the file to be opened in C lib's text mode. Since
UTF-16 is binary data, this will lead to problems with line
breaking
and file handling in general.

You should try:

import codecs
ifile = codecs.open(filename, 'rb', encoding='utf-16-le')


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904474&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 18:02:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 18:05:37 2004
Subject: [ python-Bugs-889200 ] bundlebuilder standalone app doesn't fully
	quit
Message-ID: <E1Aw82r-0007Wy-00@sc8-sf-web2.sourceforge.net>

Bugs item #889200, was opened at 2004-02-02 10:08
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder standalone app doesn't fully quit

Initial Comment:
I used bundlebuilder to create a fully standalone app (well, it fails on Jaguar, alas, but the python framework is inside the app). It works fine, but when I quit the app and try to delete it I get the following message from Finder and the item "python" in the .app is not deleted:

The operation cannot be completed because the item "Python" is in use.

The only way I&#039;ve found to delete the app is to REBOOT. Simply logging out and in again does not do the job (which I find quite startling).

I worked around the problem by making the app semi_standalone, but would rather have it fully self-contained 

It&#039;s a huge app; I&#039;ve not tried to break it down, but some things to consider:
- it uses networking (though I need not make a connection to cause this problem)
- it uses Tkinter (and yes the Tcl and Tk frameworks were installed in the app along with the Python framework)
- it uses a few threads for networking (again, though, the problem occurs even if no connection is ever made, suggesting that no threads have to be started to cause the problem)


-- Russell

I have attached the two code files I use to build the application (combined in one zip archive).

----------------------------------------------------------------------

>Comment By: Russell Owen (reowen)
Date: 2004-02-25 15:02

Message:
Logged In: YES 
user_id=431773

% pwd
/Users/rowen/PythonRO/testbuild/TUI 0.84.app/Contents/Frameworks/Python.framework/Versions/2.3
% ls -l Python 
-rwxr-xr-x  1 rowen  staff  1088276 19 Feb 09:21 Python
% otool -L Python
Python:
        /System/Library/Frameworks/Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version 2.3.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.0.0)
        /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 16.0.0)
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 496.0.0)

This data was taken on a fresh build that has not yet been run. If that makes any difference I can run the app and trash it, so only this file is left. But I'd rather not generate undeletable files unnecessarily. Anyway, I hope it helps.

This is NOT a Python built by myself. I'm using the standard Python framework that comes with Panther (in /System).

Yes it's not stunningly useful to build a fully standalone app with Panther. I originally did it because I naively thought it would run under Jaguar. I stumbled across the bug at that time and reported it.

I can still imagine uses for doing a full standalone build (if they'll be compatible with later versions of MacOS X). Mainly Python has not been 100% backwards compatible (it's been good but not perfect). I had a few changes to make before my app would run under Python 2.3. A fully standalone build would eliminate this issue.

Meanwhile, I use semi_standlone for my real releases. Partly because of this bug and partly because I'm not sure it's worth the extra app size to guard against future problems. At least for now the app is fully maintained. At some future date it could well become an issue.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 14:40

Message:
Logged In: YES 
user_id=139309

I would like to see the output of "ls -l" and "otool -L" on that file..

This is a Python framework build built by yourself, correct?  If you are 
running --standalone w/ a "/System" Python then you are not really 
doing anything useful (or supported, etc.) in the first place.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-25 14:33

Message:
Logged In: YES 
user_id=431773

First of all, after trying to empty the trash (and saying "Continue" when it complains that Python is in use), all that is left of the application bundle is:
Contents/Frameworks/Python.framework/Versions/2.3/Python

I opened the system.log and console.log and watched while I started and stopped the application and then deleted as much of it as I could. Absolutely nothing showed up in system.log. The console showed: "running sitecustomize.py" as usual on startup and then 0 (the digit zero) on quit. No messages during the partial emptying of trash.

Next I tried rm -R. It did empty the trash. I hope it doesn't cause any problems (nothing so far, but I just did it a minute ago).

Any other ideas? (Trying rm on a specific file seems sort of pointless because I think I already know which single file is tied up.)

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-02-25 12:26

Message:
Logged In: YES 
user_id=45365

Hmm. Let's first try and find out what else can be meant by "in use". It is 
probably either a filesystem-related thing or a process/framework-
related thing.

First: could you check both the console log file and the system log file 
(both with Utilities->Console) for any clues? Probably best to open both, 
then run the app, then try to delete it, and see whether anything shows 
up.

Next thing to try is good old unix "rm -r" on the app. Does that work or 
not?

If rm -r works then I think I would proceed by "rm -r"ing specific parts of 
the app, and see whether there's any part that, when removed, will 
make empty trash continue. 

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-25 11:53

Message:
Logged In: YES 
user_id=431773

I build the applications on Panther (10.3.2 with all but the 2004-02-23 security patch installed).

I checked ps -x before running the app and then again after I did all this: ran, quit and trashed the app and (unsuccessfully, as per the bug report) to empty the trash. Unfortunately there was NO change (aside from CPU time) in the ps -x listing from before to after -- same PIDs and names (and of course the same # of processes). I saved the output in case anyone wants a copy. I only checked by eye so I might have missed something very subtle, but I doubt it.

Any other tests you can think of? I'm really puzzled.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-12 20:55

Message:
Logged In: YES 
user_id=139309

Was the standalone bundle created on Jaguar or Panther?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-02-06 15:17

Message:
Logged In: YES 
user_id=45365

Russell,
could you try using "ps" (probably "ps -x", both before running the .app 
and after running it) to check that the application has indeed fully exited? 
The fact that you mention there are multiple threads somehow suggests 
that there is something still using that Python...

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-02 10:10

Message:
Logged In: YES 
user_id=431773

Note: the included BuildMacTUI.py uses semi_standalone = True, but the problem only occurs if I use standalone = True instead. Sorry for the potential confusion.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 18:04:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 18:07:05 2004
Subject: [ python-Bugs-844561 ] codecs.open().readlines(sizehint) bug
Message-ID: <E1Aw850-0007dl-00@sc8-sf-web2.sourceforge.net>

Bugs item #844561, was opened at 2003-11-18 18:22
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470

Category: Unicode
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 3
Submitted By: Jeff Epler (jepler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: codecs.open().readlines(sizehint) bug

Initial Comment:
codecs.open().readlines(sizehint) can return truncated
lines.  The attached script, which uses
readlines(sizehint) to count the number of lines in a
file, demonstrates the problem.  Correct output would
be 1000 in both cases, but different values are
returned depending on sizehint because of the truncated
lines.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 00:04

Message:
Logged In: YES 
user_id=38388

It's hard to say whether this is a bug or not. The sizehint
argument is not well documented and the way you use it
does not look a proper way to use it.

>From the docs:
""""
f the optional sizehint argument is present, instead of
reading up to EOF, whole lines totalling approximately
sizehint bytes (possibly after rounding up to an internal
buffer size) are read. 
""""

In your example the underlying open() implementation 
seems to round up the sizehint value to include the whole
line, while the codec.open() version will only read sizehint
bytes without any rounding (see the codecs.py 
implementation).


----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2003-11-18 18:28

Message:
Logged In: YES 
user_id=2772

The script triggers the assertion error using at least
python 2.3.2 (locally compiled) and python 2.2.2 (redhat 9 RPM)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 18:31:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 18:34:15 2004
Subject: [ python-Bugs-889200 ] bundlebuilder standalone app doesn't fully
	quit
Message-ID: <E1Aw8VL-0007Dk-00@sc8-sf-web1.sourceforge.net>

Bugs item #889200, was opened at 2004-02-02 13:08
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Jack Jansen (jackjansen)
Summary: bundlebuilder standalone app doesn't fully quit

Initial Comment:
I used bundlebuilder to create a fully standalone app (well, it fails on Jaguar, alas, but the python framework is inside the app). It works fine, but when I quit the app and try to delete it I get the following message from Finder and the item "python" in the .app is not deleted:

The operation cannot be completed because the item "Python" is in use.

The only way I&#039;ve found to delete the app is to REBOOT. Simply logging out and in again does not do the job (which I find quite startling).

I worked around the problem by making the app semi_standalone, but would rather have it fully self-contained 

It&#039;s a huge app; I&#039;ve not tried to break it down, but some things to consider:
- it uses networking (though I need not make a connection to cause this problem)
- it uses Tkinter (and yes the Tcl and Tk frameworks were installed in the app along with the Python framework)
- it uses a few threads for networking (again, though, the problem occurs even if no connection is ever made, suggesting that no threads have to be started to cause the problem)


-- Russell

I have attached the two code files I use to build the application (combined in one zip archive).

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 18:31

Message:
Logged In: YES 
user_id=139309

The version of Python that comes with OS X 10.3 is **NOT** future or 
backwards compatible (even with --semi-standalone!).  There are a lot of 
reasons for this, but I do not wish to explain them.

10.4's /System Python will probably be **future** compatible (assuming 
10.5 includes the same major python version), but with --semi-
standalone and not --standalone.

If you want future compatibility right now you **must** use a non-Apple 
compiled Python with --standalone.

If you want backwards compatibility, you can't have it (by default).  

Technically, you can (in theory) set up an elaborate environment such 
that you can compile Python and any extensions you need from 10.3 that 
would work on 10.2, but this is *not the default* and to my knowledge 
*nobody has tried it*.  Currently, the best solution is to have access to a 
10.2 machine for compiling and bundling Python and its extensions.  I 
don't consider this backwards compatibility though, because in either 
case you area compiling/building against OS X 10.2, whether or not you 
happen to be running it at the time.

Surely this is not what you want to hear, but it is what it is.  Sometime in 
the future, hopefully I or someone else will get this elaborate cross-
compiling environment going and write up a tutorial.  As for me, I'm FAR 
more interested in fixing current and future problems than spinning my 
wheels catering to people who can't/won't upgrade.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-25 18:02

Message:
Logged In: YES 
user_id=431773

% pwd
/Users/rowen/PythonRO/testbuild/TUI 0.84.app/Contents/Frameworks/Python.framework/Versions/2.3
% ls -l Python 
-rwxr-xr-x  1 rowen  staff  1088276 19 Feb 09:21 Python
% otool -L Python
Python:
        /System/Library/Frameworks/Python.framework/Versions/2.3/Python (compatibility version 2.3.0, current version 2.3.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.0.0)
        /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 16.0.0)
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 496.0.0)

This data was taken on a fresh build that has not yet been run. If that makes any difference I can run the app and trash it, so only this file is left. But I'd rather not generate undeletable files unnecessarily. Anyway, I hope it helps.

This is NOT a Python built by myself. I'm using the standard Python framework that comes with Panther (in /System).

Yes it's not stunningly useful to build a fully standalone app with Panther. I originally did it because I naively thought it would run under Jaguar. I stumbled across the bug at that time and reported it.

I can still imagine uses for doing a full standalone build (if they'll be compatible with later versions of MacOS X). Mainly Python has not been 100% backwards compatible (it's been good but not perfect). I had a few changes to make before my app would run under Python 2.3. A fully standalone build would eliminate this issue.

Meanwhile, I use semi_standlone for my real releases. Partly because of this bug and partly because I'm not sure it's worth the extra app size to guard against future problems. At least for now the app is fully maintained. At some future date it could well become an issue.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 17:40

Message:
Logged In: YES 
user_id=139309

I would like to see the output of "ls -l" and "otool -L" on that file..

This is a Python framework build built by yourself, correct?  If you are 
running --standalone w/ a "/System" Python then you are not really 
doing anything useful (or supported, etc.) in the first place.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-25 17:33

Message:
Logged In: YES 
user_id=431773

First of all, after trying to empty the trash (and saying "Continue" when it complains that Python is in use), all that is left of the application bundle is:
Contents/Frameworks/Python.framework/Versions/2.3/Python

I opened the system.log and console.log and watched while I started and stopped the application and then deleted as much of it as I could. Absolutely nothing showed up in system.log. The console showed: "running sitecustomize.py" as usual on startup and then 0 (the digit zero) on quit. No messages during the partial emptying of trash.

Next I tried rm -R. It did empty the trash. I hope it doesn't cause any problems (nothing so far, but I just did it a minute ago).

Any other ideas? (Trying rm on a specific file seems sort of pointless because I think I already know which single file is tied up.)

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-02-25 15:26

Message:
Logged In: YES 
user_id=45365

Hmm. Let's first try and find out what else can be meant by "in use". It is 
probably either a filesystem-related thing or a process/framework-
related thing.

First: could you check both the console log file and the system log file 
(both with Utilities->Console) for any clues? Probably best to open both, 
then run the app, then try to delete it, and see whether anything shows 
up.

Next thing to try is good old unix "rm -r" on the app. Does that work or 
not?

If rm -r works then I think I would proceed by "rm -r"ing specific parts of 
the app, and see whether there's any part that, when removed, will 
make empty trash continue. 

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-25 14:53

Message:
Logged In: YES 
user_id=431773

I build the applications on Panther (10.3.2 with all but the 2004-02-23 security patch installed).

I checked ps -x before running the app and then again after I did all this: ran, quit and trashed the app and (unsuccessfully, as per the bug report) to empty the trash. Unfortunately there was NO change (aside from CPU time) in the ps -x listing from before to after -- same PIDs and names (and of course the same # of processes). I saved the output in case anyone wants a copy. I only checked by eye so I might have missed something very subtle, but I doubt it.

Any other tests you can think of? I'm really puzzled.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-12 23:55

Message:
Logged In: YES 
user_id=139309

Was the standalone bundle created on Jaguar or Panther?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-02-06 18:17

Message:
Logged In: YES 
user_id=45365

Russell,
could you try using "ps" (probably "ps -x", both before running the .app 
and after running it) to check that the application has indeed fully exited? 
The fact that you mention there are multiple threads somehow suggests 
that there is something still using that Python...

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-02 13:10

Message:
Logged In: YES 
user_id=431773

Note: the included BuildMacTUI.py uses semi_standalone = True, but the problem only occurs if I use standalone = True instead. Sorry for the potential confusion.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889200&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 20:14:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 20:16:23 2004
Subject: [ python-Bugs-844561 ] codecs.open().readlines(sizehint) bug
Message-ID: <E1AwA6D-0001IC-00@sc8-sf-web3.sourceforge.net>

Bugs item #844561, was opened at 2003-11-18 11:22
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470

Category: Unicode
Group: Python 2.2
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeff Epler (jepler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: codecs.open().readlines(sizehint) bug

Initial Comment:
codecs.open().readlines(sizehint) can return truncated
lines.  The attached script, which uses
readlines(sizehint) to count the number of lines in a
file, demonstrates the problem.  Correct output would
be 1000 in both cases, but different values are
returned depending on sizehint because of the truncated
lines.

----------------------------------------------------------------------

>Comment By: Jeff Epler (jepler)
Date: 2004-02-25 19:14

Message:
Logged In: YES 
user_id=2772

To me, the phrase "*whole lines* totalling approximately
sizehint" means that no item from readlines(sizehint) will
be an incomplete line.  I don't understand why this
requirement isn't clearly indicated to you by the text you
included in your comments.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-25 17:04

Message:
Logged In: YES 
user_id=38388

It's hard to say whether this is a bug or not. The sizehint
argument is not well documented and the way you use it
does not look a proper way to use it.

>From the docs:
""""
f the optional sizehint argument is present, instead of
reading up to EOF, whole lines totalling approximately
sizehint bytes (possibly after rounding up to an internal
buffer size) are read. 
""""

In your example the underlying open() implementation 
seems to round up the sizehint value to include the whole
line, while the codec.open() version will only read sizehint
bytes without any rounding (see the codecs.py 
implementation).


----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2003-11-18 11:28

Message:
Logged In: YES 
user_id=2772

The script triggers the assertion error using at least
python 2.3.2 (locally compiled) and python 2.2.2 (redhat 9 RPM)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 21:37:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 21:40:04 2004
Subject: [ python-Feature Requests-900502 ] bundlebuilder: some way to add
	non-py files in packages
Message-ID: <E1AwBPD-0005sx-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #900502, was opened at 2004-02-19 13:30
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900502&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bundlebuilder: some way to add non-py files in packages

Initial Comment:
I would like some way to load non-python code that is 
contained in packages. In other words, suppose I have:
maindir/
  helpdir/
    __init__.py
    index.html
    ...other python code and help files

I&#039;d like some way to specify that the code in helpdir be 
loaded as code (compiled and the source discarded) but that 
the other files also be copied over. Presently includePackages 
only copies over python files.

The best workaround I&#039;ve found so far is to specify the 
package in two separate arguments to buildapp: 
includePackages and resources. That copies everything 
(including the python source) and also compiles everything, 
so one ends up with both .py and .pyc files. I then look in 
that folder and discard the python source after 
bundlebuilder is finished. (I suppose that step is optional.)

Simply modifying includePackages so it included non-python 
files is my first thought. It might occasionally include stuff 
that wasn&#039;t wanted, but aside from on occasional README 
or something, I doubt it would amount to anything 
significant in most cases.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 21:37

Message:
Logged In: YES 
user_id=139309

why not keep your code and data in separate folders?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900502&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 21:39:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 21:42:06 2004
Subject: [ python-Feature Requests-900514 ] bundlebuilder: easily keep main
	routine in orig location
Message-ID: <E1AwBRB-00065Z-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #900514, was opened at 2004-02-19 13:44
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900514&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bundlebuilder: easily keep main routine in orig location

Initial Comment:
I&#039;d like to ask that bundlebuilder.py keep the main routine in 
its original location with respect to whatever package it 
appears in, i.e. if the app&#039;s main is
MyPgk/Main.py

then the code is put in MyPkg:
Contents/Resources/Modules.zip
      /MyPkg/Main.py

or if no zipping is done:
Contents/Resources/MyPkg/Main.py

I fear this may be too difficult to be worth the work, but I 
wasn&#039;t sure and felt it better to ask.

The issue is (as in my 2 previous bundlebuilder requests) 
making it easier to write cross-platform code. If one carefully 
develops code for Mac then one can easily organize it such 
that it fits perfectly within bundlebuilder&#039;s assumptions.

But in my case I wrote code to run under unix first, then 
tried to get a working double-clickable Mac app, and it was a 
a surprising amount of work. Among other things, I had to 
rewrite my Main.py so it could be moved relative to its 
package (not a really big deal, but surprising). The other 
requests would simplify or eliminate cleanup work I do after 
the bundle is built.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 21:39

Message:
Logged In: YES 
user_id=139309

This doesn't *really* make sense.. is it too hard to have a bootstrap 
script that imports and executes this?  Isn't that what you would have on 
other platforms?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900514&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 21:43:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 21:45:52 2004
Subject: [ python-Feature Requests-887237 ] Machine integers
Message-ID: <E1AwBUr-00067u-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #887237, was opened at 2004-01-29 15:34
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=887237&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fredrik Johansson (fredrik_j)
Assigned to: Nobody/Anonymous (nobody)
Summary: Machine integers

Initial Comment:
I think it&#039;d be useful with a built-in module (I
propose the name &#039;mint&#039; :), providing classes for
emulating machine ints. There should be support for
ints of different sizes (at least 8, 16, 32, 64),
signedness and endianness. The machine ints would react
to overflow (negative values) and bit-level operations
in the same way their C equivalents would.

One idea for a feature would be a intobj.pack() (or
str() or whatever) method that could be used instead of
the struct module&#039;s pack(). int16(12345).pack() ->
"\x30\x39". int32(-1).pack() -> "\0xff\0xff\0xff\0xff",
etc.

A related idea is that these ints could provide slicing
to extract individual sets of bits or bytes. For
example, uint32()[8:16] could return an int (uint8?)
made from the bits in the int&#039;s second byte (whether
it&#039;s the second from the left or the right might be
fuzzy, I do realize).

Applications for this would be algorithmic code
involving bit fiddling (useful for cryptographic
applications, perhaps) and, obviously, programs that
have to operate on any binary data.  It might also
resolve some issues related to the unification of longs
and ints.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 21:43

Message:
Logged In: YES 
user_id=139309

If I were providing slicing on bits I would say that foo[n] is bool(foo & 
(1<<n)) .. which means bit 0 is least significant, and bit N is most 
significant.  I don't think any other way would make sense.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-01-30 09:16

Message:
Logged In: YES 
user_id=11105

You might look at the ctypes module (google for it) - it
implements mutable C compatible data types.

----------------------------------------------------------------------

Comment By: Fredrik Johansson (fredrik_j)
Date: 2004-01-30 09:08

Message:
Logged In: YES 
user_id=756835

As for mainstream uses, I think replacing struct.pack would
be one.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-01-29 19:35

Message:
Logged In: YES 
user_id=80475

FTI, there was a related feature request,
www.python.org/sf/846568 for treating numbers as bitarrays.
 As proposed, it was invalid because numbers in Python are
immutable (no bit assignments allowed).

That could be combined with this idea generic numeric
register class that optionally specifies size (if bound),
base, endianess, etc.  

bcdreg = register(places=5, base=10)
bcdreg.assign(697)
bcdreg[-1] --> 7
bcdreg.multiply(1000) --> 97000

None of this is for the mainstream user and it would be
unlikely to ever be included in the standard library.  The
best approach would be to experiment with an API in pure
python, perhaps publish it as a recipe, and if it is well
received, put a C version on the vaults of parnassus.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=887237&group_id=5470

From noreply at sourceforge.net  Wed Feb 25 21:55:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Feb 25 21:57:55 2004
Subject: [ python-Feature Requests-904770 ] http://doc.python.org
Message-ID: <E1AwBgV-0006Z1-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #904770, was opened at 2004-02-25 21:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=904770&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: http://doc.python.org

Initial Comment:
If http://python.org/doc/ were mirrored at http://doc.python.org/ it 
would be much easier to search, especially via google.

f.ex. "datetime site:doc.python.org"

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=904770&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 04:51:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 04:53:52 2004
Subject: [ python-Bugs-844561 ] codecs.open().readlines(sizehint) bug
Message-ID: <E1AwIAe-00060g-00@sc8-sf-web2.sourceforge.net>

Bugs item #844561, was opened at 2003-11-18 18:22
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470

Category: Unicode
Group: Python 2.2
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeff Epler (jepler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: codecs.open().readlines(sizehint) bug

Initial Comment:
codecs.open().readlines(sizehint) can return truncated
lines.  The attached script, which uses
readlines(sizehint) to count the number of lines in a
file, demonstrates the problem.  Correct output would
be 1000 in both cases, but different values are
returned depending on sizehint because of the truncated
lines.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 10:51

Message:
Logged In: YES 
user_id=38388

Good catch. I must have overread the "whole lines" bit :-)

In that case, it's probably best to have .readlines() ignore
the sizehint argument altogether. An efficient implementation
is hard to do since the line breaking is not done at C level,
but after the data has been read.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-02-26 02:14

Message:
Logged In: YES 
user_id=2772

To me, the phrase "*whole lines* totalling approximately
sizehint" means that no item from readlines(sizehint) will
be an incomplete line.  I don't understand why this
requirement isn't clearly indicated to you by the text you
included in your comments.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 00:04

Message:
Logged In: YES 
user_id=38388

It's hard to say whether this is a bug or not. The sizehint
argument is not well documented and the way you use it
does not look a proper way to use it.

>From the docs:
""""
f the optional sizehint argument is present, instead of
reading up to EOF, whole lines totalling approximately
sizehint bytes (possibly after rounding up to an internal
buffer size) are read. 
""""

In your example the underlying open() implementation 
seems to round up the sizehint value to include the whole
line, while the codec.open() version will only read sizehint
bytes without any rounding (see the codecs.py 
implementation).


----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2003-11-18 18:28

Message:
Logged In: YES 
user_id=2772

The script triggers the assertion error using at least
python 2.3.2 (locally compiled) and python 2.2.2 (redhat 9 RPM)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 05:11:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 05:14:17 2004
Subject: [ python-Bugs-788421 ] bsddb btree set_location() semantics changed
Message-ID: <E1AwIUe-00075d-00@sc8-sf-web4.sourceforge.net>

Bugs item #788421, was opened at 2003-08-13 16:21
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788421&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory P. Smith (greg)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb btree set_location() semantics changed

Initial Comment:
In the old bsddb module a bsddb.btopen(..) database
would return the next available key+value on a
set_location(key) call when key did not exist in the
database.  In python 2.3 (pybsddb) it raises an
exception and leaves the cursor at an unknown position
in the database.

[reported by Anthony McDonaly on comp.lang.python]

>>> import os
>>> import bsddb
>>> os.chdir(&#039;/tmp&#039;)
>>> my_data = bsddb.btopen(&#039;testing&#039;, &#039;c&#039;)
>>> for i in range(10):
...   if i == 5:
...     pass
...   else:
...     my_data[&#039;%d&#039;%i] = &#039;%d&#039;%(i*i)
...
>>> my_data.keys()
[&#039;0&#039;, &#039;1&#039;, &#039;2&#039;, &#039;3&#039;, &#039;4&#039;, &#039;6&#039;, &#039;7&#039;, &#039;8&#039;, &#039;9&#039;]
>>> my_data.sync()
>>> my_data.set_location(&#039;5&#039;)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/space/python-2.3/lib/python2.3/bsddb/__init__.py",
line 117, in set_location
    return self.dbc.set(key)
_bsddb.DBNotFoundError: (-30991, &#039;DB_NOTFOUND: No
matching key/data pair found&#039;)

Correct behaviour would have been to return (&#039;6&#039;, &#039;36&#039;)


----------------------------------------------------------------------

>Comment By: Gregory P. Smith (greg)
Date: 2004-02-26 02:11

Message:
Logged In: YES 
user_id=413

Yes this is a bug.  The set_location() method should have been calling set_range() rather than set() internally.

Fixing that exposed another bug: set_range() would crash when looking up a key that exists in hash or rn databases.

Both bugs have been fixed to fix this one in python 2.4 & pybsddb CVS.

This bugfix should go into python 2.3.4.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788421&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 07:51:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 07:53:45 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1AwKyy-0004ij-00@sc8-sf-web3.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 21:47
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Open
Resolution: Fixed
>Priority: 3
Submitted By: Arman Bostani (arman0)
Assigned to: Michael Hudson (mwh)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float(&#039;nan&#039;) evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-02-26 12:51

Message:
Logged In: YES 
user_id=6656

Hmm.

I agree the situation wrt. float_compare as in CVS is a
problem.  Not sure I have the courage to have float_compare
starting to set exceptions, though.  Just removing
float_compare seems to be a conservative change (yes, it can
give silly answers, but this is nothing new).

I certainly don't have the courage to change
PyObject_Compare unless someone like Tim or Guido says I
should :-)

----------------------------------------------------------------------

Comment By: Paul Eggert (eggert)
Date: 2004-02-20 21:10

Message:
Logged In: YES 
user_id=17848

Sorry, I didn't intend a rant, and I apologize if any
offense was given.  I'll try to use a milder tone
henceforth.

To answer Michael's question: yes, now that your patch is
installed, float_compare is incompatible with rich
comparison; for example cmp(NaN,1.0) returns 0 even though
NaN==1.0 returns False.

Another problem: cmp() initially uses pointer comparison to
compare objects, so if x is a NaN then cmp(x,x) returns 0.

I don't think that removing float_compare will fix the
problem, as it would simply cause cmp to return an incorrect
value when given a NaN.

If you prefer IEEE semantics to sorting NaNs before numbers,
another possibility is for cmp to raise an exception when
given a NaN, since in that case cmp can't return any value
that is compatible with IEEE floating point.

Here's a patch to implement this proposal.  It does not rely
on isnan or a substitute, so I hope this answers Tim's
objection.  Note that PyObject_Compare needs a minor change,
too; since user-defined types may have the same problem that
Float does, it's simplest just to omit the optimization
there.

===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.2
retrieving revision 2.3.3.3
diff -pu -r2.3.3.2 -r2.3.3.3
--- Objects/floatobject.c	2004/02/20 19:45:01	2.3.3.2
+++ Objects/floatobject.c	2004/02/20 21:04:20	2.3.3.3
@@ -367,7 +367,15 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	if (i < j)
+		return -1;
+	if (i > j)
+		return 1;
+	if (i == j)
+		return 0;
+	PyErr_SetString(PyExc_FloatingPointError,
+			"cannot compare NaNs using cmp");
+	return -2;
 }
 
 static PyObject*
===================================================================
RCS file: Objects/object.c,v
retrieving revision 2.3.3.0
retrieving revision 2.3.3.1
diff -pu -r2.3.3.0 -r2.3.3.1
--- Objects/object.c	2003/04/18 00:45:58	2.3.3.0
+++ Objects/object.c	2004/02/20 21:04:20	2.3.3.1
@@ -877,8 +877,6 @@ PyObject_Compare(PyObject *v, PyObject *
 		PyErr_BadInternalCall();
 		return -1;
 	}
-	if (v == w)
-		return 0;
 	vtp = v->ob_type;
 	compare_nesting++;
 	if (compare_nesting > NESTING_LIMIT &&


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-20 11:09

Message:
Logged In: YES 
user_id=6656

Paul, I appreciate your attention to detail, but your last
comment is essentially a rant that puts words into Tim's and
my mouth.

My patch (which is what got checked in) *is* attached to
this report, or you can see it on the python-checkins list.
 There was some ancillary discussion on python-dev (under
the admittedly inscrutable title of "Weekly Python Bug/Patch
Summary") about this, where it was uncovered that MSVC 7.1
(which is what Python 2.4 will be compiled with) adheres to
the C99 rules for comparisons involving NaNs.  So with my
patch, on all major platforms, float comparisons are likely
to follow C99 rules in Python 2.4.  We're still not going to
promise anything, though.

I admit to not doing much research on whether I should/could
remove float_compare.  It seems that perhaps I should.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 20:22

Message:
Logged In: YES 
user_id=31435

I specifically said C89.  Python doesn't require C99 support, 
and can't yet, because the majority of compilers used to 
compile Python aren't yet C99 compilers.  Even in C99, that x!
=x is 1 for NaN is optional behavior, depending on whether the 
implementation chooses to define __STDC_IEC_559__.

The point of my example was solely the result of x==x.  It 
doesn't matter how a NaN got put into x, MSVC 6 generates 
code that returns true regardless.  It wasn't constructed to 
confuse anything -- to the contrary, it shows about the most 
straightforward way to *get* a NaN under MSVC 6, short of 
playing tricks with bit representation.

Michael's patch is a more efficient approach regardless.  If 
Python is to grow an isnan macro (which his patch doesn't 
need), then it shoiuld grow an isnan() macro that works on all 
platforms with 754 HW (else it appears to promise thing it 
can't deliver).

Going on to call NaN "less than" everything else goes beyond 
anything C99 says, and is a debate of its own.

No, he didn't remove float_compare().  He could, but only cmp
() will invoke it now.

----------------------------------------------------------------------

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 19:55

Message:
Logged In: YES 
user_id=17848

C99 does say what happens when NaNs are
compared.  See, for example, section 7.12.14,
which says that NaNs are unordered with respect
to other floating point values, and section
7.12.14.1, which says that x>y is equivalent to
isgreater(x,y) and therefore returns false if
either x or y is a NaN (unless the "invalid"
floating-point exception occurs, which isn't
happening here and even if it did happen the
original code would be broken anyway).

Your argument is that any code that uses NaNs
returns garbage and so we should give up.  But
then you have no logical reason to either favor
or oppose this patch, as it doesn't alter
Python's behavior on non-NaN arguments.

It's clear the the patch does fix the comparison
problem on most existing platforms.  It actually
works on Solaris sparc, and I'm sure that it
will work on a wide variety of other important
platforms.

The fact that you've found an incompatibility
between MSVC 6 and C99 on one example does not
mean that the proposed patch won't work: it
merely means that MSVC 6 won't work on your
example (which is deliberately constructed to
confuse pre-C99 compilers).  The proposed patch
doesn't contain confusing code like that, so it
should work even on pre-C99 compilers.

I'm not speaking just from theory here.  Similar
code has been in GNU sort since 1999, and it
works fine in practice.

Since the patch fixes the bug on many (perhaps
all) real platforms, and it can't introduce a
bug on any platform, the patch is a win.

Michael Hudson said "Consider the attached."
but nothing was attached.  I gather from his
comments that he added rich comparisons for
floats.  This will work if the code never
invokes the 2.3.3 float_compare -- so can I take
it that he removed float_compare?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:39

Message:
Logged In: YES 
user_id=6656

Tim said yes.

Objects/floatobject.c revision 2.127
Misc/NEWS revision 1.936

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:01

Message:
Logged In: YES 
user_id=6656

Consider the attached.  It implements rich comparisons for
floats, which makes the behaviour on linux at least very
much less silly.  All tests except for the
considered-hopeless-on-this box audio tests and the new
test_tcl pass.  Even test_bsddb passed! Twice!  (I'm not
sure I can claim credit for this :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 17:34

Message:
Logged In: YES 
user_id=31435

Sorry, the patch can't work:  C89 says nothing about what 
happens when NaNs are compared, and it's in fact not the 
case across platforms that "x != x" returns 1 when x is a NaN.

The most important counter-example for Python is that the 
following prints

1.#INF
-1.#IND
1

under MSVC 6.

#include <stdio.h>

void main()
{
    double x = 1e300 * 1e300;
    printf("%g\n", x);
    x -= x;
    printf("%g\n", x);
    printf("%d\n", x == x);
}


----------------------------------------------------------------------

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 06:39

Message:
Logged In: YES 
user_id=17848

There's an easy fix.  Python has long mishandled IEEE
special values
(see bugs 445484 and 737648, and see PEP 42 "Non-accidental
IEEE-754
support" as well as PEP 754), and solving the problem in
general will
be some work.  However, solving the NaN-comparison problem
is easy:
simply sort NaNs consistently before all numbers.  This is
the same
algorithm that GNU "sort -g" has used for quite some time.

===================================================================
RCS file: Include/pyport.h,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Include/pyport.h
--- Include/pyport.h	2003/09/30 14:56:50	2.3.3.0
+++ Include/pyport.h	2004/02/19 06:06:10
@@ -221,6 +221,13 @@ extern "C" {
 #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
 #endif
 
+/* Py_IS_NAN(X)
+ * Return 1 if float or double arg is not a number (NaN),
else 0.
+ * Caution:
+ *    X is evaluated more than once.
+ */
+#define Py_IS_NAN(X) ((X) != (X))
+
 /* Py_IS_INFINITY(X)
  * Return 1 if float or double arg is an infinity, else 0.
  * Caution:
===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Objects/floatobject.c
--- Objects/floatobject.c	2003/06/28 20:04:24	2.3.3.0
+++ Objects/floatobject.c	2004/02/19 06:03:37
@@ -367,7 +367,21 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	int c;
+	/* Because of NaNs IEEE arithmetic is not a total order.
+	 * Python works better with total orders, so use the same
+	 * total order that GNU sort does: NaNs sort before numbers,
+	 * and NaNs are sorted by internal bit-pattern.
+	 */
+	return ((i < j) ? -1
+		: (i > j) ? 1
+		: (i == j) ? 0
+		: !Py_IS_NAN(j) ? -1 /* i is NaN, j is not */
+		: !Py_IS_NAN(i) ? 1  /* j is NAN, i is not */
+		: /* i and j are both NaNs; compare them bitwise */
+		  ((c = memcmp(&v->ob_fval, &w->ob_fval, sizeof(v->ob_fval)))
+		   < 0) ? -1
+		: (c > 0));
 }
 
 static long


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-18 17:46

Message:
Logged In: YES 
user_id=6656

Man, that's strange (I see the same behaviour on my redhat 9
box with 2.3.3).

I don't have time to dig right now, but if you want to,
playing with equivalent C programs would be a very good start.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 08:09:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 08:11:38 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1AwLG9-0007S0-00@sc8-sf-web2.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 22:47
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 3
Submitted By: Arman Bostani (arman0)
Assigned to: Michael Hudson (mwh)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float(&#039;nan&#039;) evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 14:09

Message:
Logged In: YES 
user_id=38388

Michael,

please be more careful about these changes: we certainly do
not want to lose a significant number of cycles just to
remedy this rather uncommon error situation.

The cleanest solution seems to be to just raise an exception
in the compare logic (which is perfectly OK). Removing the
tp_compare slot will result in PyObject_Compare() to take a
different path and is likely going to cause a performance hit.

Whatever you chose to do about this, please make sure that
we don't lose performance in float compares. pybench has a
special test for float comparisons which you could use as
basis for this.

Thanks.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-26 13:51

Message:
Logged In: YES 
user_id=6656

Hmm.

I agree the situation wrt. float_compare as in CVS is a
problem.  Not sure I have the courage to have float_compare
starting to set exceptions, though.  Just removing
float_compare seems to be a conservative change (yes, it can
give silly answers, but this is nothing new).

I certainly don't have the courage to change
PyObject_Compare unless someone like Tim or Guido says I
should :-)

----------------------------------------------------------------------

Comment By: Paul Eggert (eggert)
Date: 2004-02-20 22:10

Message:
Logged In: YES 
user_id=17848

Sorry, I didn't intend a rant, and I apologize if any
offense was given.  I'll try to use a milder tone
henceforth.

To answer Michael's question: yes, now that your patch is
installed, float_compare is incompatible with rich
comparison; for example cmp(NaN,1.0) returns 0 even though
NaN==1.0 returns False.

Another problem: cmp() initially uses pointer comparison to
compare objects, so if x is a NaN then cmp(x,x) returns 0.

I don't think that removing float_compare will fix the
problem, as it would simply cause cmp to return an incorrect
value when given a NaN.

If you prefer IEEE semantics to sorting NaNs before numbers,
another possibility is for cmp to raise an exception when
given a NaN, since in that case cmp can't return any value
that is compatible with IEEE floating point.

Here's a patch to implement this proposal.  It does not rely
on isnan or a substitute, so I hope this answers Tim's
objection.  Note that PyObject_Compare needs a minor change,
too; since user-defined types may have the same problem that
Float does, it's simplest just to omit the optimization
there.

===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.2
retrieving revision 2.3.3.3
diff -pu -r2.3.3.2 -r2.3.3.3
--- Objects/floatobject.c	2004/02/20 19:45:01	2.3.3.2
+++ Objects/floatobject.c	2004/02/20 21:04:20	2.3.3.3
@@ -367,7 +367,15 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	if (i < j)
+		return -1;
+	if (i > j)
+		return 1;
+	if (i == j)
+		return 0;
+	PyErr_SetString(PyExc_FloatingPointError,
+			"cannot compare NaNs using cmp");
+	return -2;
 }
 
 static PyObject*
===================================================================
RCS file: Objects/object.c,v
retrieving revision 2.3.3.0
retrieving revision 2.3.3.1
diff -pu -r2.3.3.0 -r2.3.3.1
--- Objects/object.c	2003/04/18 00:45:58	2.3.3.0
+++ Objects/object.c	2004/02/20 21:04:20	2.3.3.1
@@ -877,8 +877,6 @@ PyObject_Compare(PyObject *v, PyObject *
 		PyErr_BadInternalCall();
 		return -1;
 	}
-	if (v == w)
-		return 0;
 	vtp = v->ob_type;
 	compare_nesting++;
 	if (compare_nesting > NESTING_LIMIT &&


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-20 12:09

Message:
Logged In: YES 
user_id=6656

Paul, I appreciate your attention to detail, but your last
comment is essentially a rant that puts words into Tim's and
my mouth.

My patch (which is what got checked in) *is* attached to
this report, or you can see it on the python-checkins list.
 There was some ancillary discussion on python-dev (under
the admittedly inscrutable title of "Weekly Python Bug/Patch
Summary") about this, where it was uncovered that MSVC 7.1
(which is what Python 2.4 will be compiled with) adheres to
the C99 rules for comparisons involving NaNs.  So with my
patch, on all major platforms, float comparisons are likely
to follow C99 rules in Python 2.4.  We're still not going to
promise anything, though.

I admit to not doing much research on whether I should/could
remove float_compare.  It seems that perhaps I should.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 21:22

Message:
Logged In: YES 
user_id=31435

I specifically said C89.  Python doesn't require C99 support, 
and can't yet, because the majority of compilers used to 
compile Python aren't yet C99 compilers.  Even in C99, that x!
=x is 1 for NaN is optional behavior, depending on whether the 
implementation chooses to define __STDC_IEC_559__.

The point of my example was solely the result of x==x.  It 
doesn't matter how a NaN got put into x, MSVC 6 generates 
code that returns true regardless.  It wasn't constructed to 
confuse anything -- to the contrary, it shows about the most 
straightforward way to *get* a NaN under MSVC 6, short of 
playing tricks with bit representation.

Michael's patch is a more efficient approach regardless.  If 
Python is to grow an isnan macro (which his patch doesn't 
need), then it shoiuld grow an isnan() macro that works on all 
platforms with 754 HW (else it appears to promise thing it 
can't deliver).

Going on to call NaN "less than" everything else goes beyond 
anything C99 says, and is a debate of its own.

No, he didn't remove float_compare().  He could, but only cmp
() will invoke it now.

----------------------------------------------------------------------

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 20:55

Message:
Logged In: YES 
user_id=17848

C99 does say what happens when NaNs are
compared.  See, for example, section 7.12.14,
which says that NaNs are unordered with respect
to other floating point values, and section
7.12.14.1, which says that x>y is equivalent to
isgreater(x,y) and therefore returns false if
either x or y is a NaN (unless the "invalid"
floating-point exception occurs, which isn't
happening here and even if it did happen the
original code would be broken anyway).

Your argument is that any code that uses NaNs
returns garbage and so we should give up.  But
then you have no logical reason to either favor
or oppose this patch, as it doesn't alter
Python's behavior on non-NaN arguments.

It's clear the the patch does fix the comparison
problem on most existing platforms.  It actually
works on Solaris sparc, and I'm sure that it
will work on a wide variety of other important
platforms.

The fact that you've found an incompatibility
between MSVC 6 and C99 on one example does not
mean that the proposed patch won't work: it
merely means that MSVC 6 won't work on your
example (which is deliberately constructed to
confuse pre-C99 compilers).  The proposed patch
doesn't contain confusing code like that, so it
should work even on pre-C99 compilers.

I'm not speaking just from theory here.  Similar
code has been in GNU sort since 1999, and it
works fine in practice.

Since the patch fixes the bug on many (perhaps
all) real platforms, and it can't introduce a
bug on any platform, the patch is a win.

Michael Hudson said "Consider the attached."
but nothing was attached.  I gather from his
comments that he added rich comparisons for
floats.  This will work if the code never
invokes the 2.3.3 float_compare -- so can I take
it that he removed float_compare?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 20:39

Message:
Logged In: YES 
user_id=6656

Tim said yes.

Objects/floatobject.c revision 2.127
Misc/NEWS revision 1.936

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 20:01

Message:
Logged In: YES 
user_id=6656

Consider the attached.  It implements rich comparisons for
floats, which makes the behaviour on linux at least very
much less silly.  All tests except for the
considered-hopeless-on-this box audio tests and the new
test_tcl pass.  Even test_bsddb passed! Twice!  (I'm not
sure I can claim credit for this :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 18:34

Message:
Logged In: YES 
user_id=31435

Sorry, the patch can't work:  C89 says nothing about what 
happens when NaNs are compared, and it's in fact not the 
case across platforms that "x != x" returns 1 when x is a NaN.

The most important counter-example for Python is that the 
following prints

1.#INF
-1.#IND
1

under MSVC 6.

#include <stdio.h>

void main()
{
    double x = 1e300 * 1e300;
    printf("%g\n", x);
    x -= x;
    printf("%g\n", x);
    printf("%d\n", x == x);
}


----------------------------------------------------------------------

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 07:39

Message:
Logged In: YES 
user_id=17848

There's an easy fix.  Python has long mishandled IEEE
special values
(see bugs 445484 and 737648, and see PEP 42 "Non-accidental
IEEE-754
support" as well as PEP 754), and solving the problem in
general will
be some work.  However, solving the NaN-comparison problem
is easy:
simply sort NaNs consistently before all numbers.  This is
the same
algorithm that GNU "sort -g" has used for quite some time.

===================================================================
RCS file: Include/pyport.h,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Include/pyport.h
--- Include/pyport.h	2003/09/30 14:56:50	2.3.3.0
+++ Include/pyport.h	2004/02/19 06:06:10
@@ -221,6 +221,13 @@ extern "C" {
 #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
 #endif
 
+/* Py_IS_NAN(X)
+ * Return 1 if float or double arg is not a number (NaN),
else 0.
+ * Caution:
+ *    X is evaluated more than once.
+ */
+#define Py_IS_NAN(X) ((X) != (X))
+
 /* Py_IS_INFINITY(X)
  * Return 1 if float or double arg is an infinity, else 0.
  * Caution:
===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Objects/floatobject.c
--- Objects/floatobject.c	2003/06/28 20:04:24	2.3.3.0
+++ Objects/floatobject.c	2004/02/19 06:03:37
@@ -367,7 +367,21 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	int c;
+	/* Because of NaNs IEEE arithmetic is not a total order.
+	 * Python works better with total orders, so use the same
+	 * total order that GNU sort does: NaNs sort before numbers,
+	 * and NaNs are sorted by internal bit-pattern.
+	 */
+	return ((i < j) ? -1
+		: (i > j) ? 1
+		: (i == j) ? 0
+		: !Py_IS_NAN(j) ? -1 /* i is NaN, j is not */
+		: !Py_IS_NAN(i) ? 1  /* j is NAN, i is not */
+		: /* i and j are both NaNs; compare them bitwise */
+		  ((c = memcmp(&v->ob_fval, &w->ob_fval, sizeof(v->ob_fval)))
+		   < 0) ? -1
+		: (c > 0));
 }
 
 static long


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-18 18:46

Message:
Logged In: YES 
user_id=6656

Man, that's strange (I see the same behaviour on my redhat 9
box with 2.3.3).

I don't have time to dig right now, but if you want to,
playing with equivalent C programs would be a very good start.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 08:11:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 08:14:02 2004
Subject: [ python-Bugs-905046 ] test_tcl fails -- "can't find package Tclx"
Message-ID: <E1AwLIN-0007Yp-00@sc8-sf-web2.sourceforge.net>

Bugs item #905046, was opened at 2004-02-26 13:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905046&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: David Ascher (david_ascher)
Summary: test_tcl fails -- "can't find package Tclx"

Initial Comment:
As summary, really.  Fairly stock Redhat 9 install, CVS
as of a few minutes back.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905046&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 09:50:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 09:53:22 2004
Subject: [ python-Bugs-844561 ] codecs.open().readlines(sizehint) bug
Message-ID: <E1AwMqc-00064h-00@sc8-sf-web2.sourceforge.net>

Bugs item #844561, was opened at 2003-11-18 11:22
Message generated for change (Comment added) made by jepler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470

Category: Unicode
Group: Python 2.2
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeff Epler (jepler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: codecs.open().readlines(sizehint) bug

Initial Comment:
codecs.open().readlines(sizehint) can return truncated
lines.  The attached script, which uses
readlines(sizehint) to count the number of lines in a
file, demonstrates the problem.  Correct output would
be 1000 in both cases, but different values are
returned depending on sizehint because of the truncated
lines.

----------------------------------------------------------------------

>Comment By: Jeff Epler (jepler)
Date: 2004-02-26 08:50

Message:
Logged In: YES 
user_id=2772

Ignoring sizehint and reading the whole file is probably
better than truncating lines.  This change would also fix
another bug I realized exists in codecs readlines(sizehint)
currently: if it reads only part of a multi-byte character,
you get a decoding error...

A slightly more complicated approach would be to read
sizehint bytes and then while the result doesn't end in a
newline, read one more byte and decode again.  When sizehint
is large enough, doing byte-at-a-time reading of the last
half-line shouldn't be that bad for performance.  No, I
don't have a patch.

Is there a way to differentiate between "the byte string
ends with an incomplete multi-byte character" and "the byte
string contains an invalid sequence of bytes"?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 03:51

Message:
Logged In: YES 
user_id=38388

Good catch. I must have overread the "whole lines" bit :-)

In that case, it's probably best to have .readlines() ignore
the sizehint argument altogether. An efficient implementation
is hard to do since the line breaking is not done at C level,
but after the data has been read.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-02-25 19:14

Message:
Logged In: YES 
user_id=2772

To me, the phrase "*whole lines* totalling approximately
sizehint" means that no item from readlines(sizehint) will
be an incomplete line.  I don't understand why this
requirement isn't clearly indicated to you by the text you
included in your comments.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-25 17:04

Message:
Logged In: YES 
user_id=38388

It's hard to say whether this is a bug or not. The sizehint
argument is not well documented and the way you use it
does not look a proper way to use it.

>From the docs:
""""
f the optional sizehint argument is present, instead of
reading up to EOF, whole lines totalling approximately
sizehint bytes (possibly after rounding up to an internal
buffer size) are read. 
""""

In your example the underlying open() implementation 
seems to round up the sizehint value to include the whole
line, while the codec.open() version will only read sizehint
bytes without any rounding (see the codecs.py 
implementation).


----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2003-11-18 11:28

Message:
Logged In: YES 
user_id=2772

The script triggers the assertion error using at least
python 2.3.2 (locally compiled) and python 2.2.2 (redhat 9 RPM)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 10:20:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 10:22:52 2004
Subject: [ python-Bugs-844561 ] codecs.open().readlines(sizehint) bug
Message-ID: <E1AwNJJ-0000kU-00@sc8-sf-web4.sourceforge.net>

Bugs item #844561, was opened at 2003-11-18 18:22
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470

Category: Unicode
Group: Python 2.2
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeff Epler (jepler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: codecs.open().readlines(sizehint) bug

Initial Comment:
codecs.open().readlines(sizehint) can return truncated
lines.  The attached script, which uses
readlines(sizehint) to count the number of lines in a
file, demonstrates the problem.  Correct output would
be 1000 in both cases, but different values are
returned depending on sizehint because of the truncated
lines.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 16:20

Message:
Logged In: YES 
user_id=38388

Ok, I'll fix codecs.py to ignore the sizehint argument then
(should not break any code; at worst it might cause problems
with MemoryOverflows).

To answer your question: whether a byte string is incomplete
or in error depends on the encoding and only the codec can
decide what to do. While the codecs do differentiate and the
error callback logic could be used to work out a correct
solution, this would require a lot of work.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-02-26 15:50

Message:
Logged In: YES 
user_id=2772

Ignoring sizehint and reading the whole file is probably
better than truncating lines.  This change would also fix
another bug I realized exists in codecs readlines(sizehint)
currently: if it reads only part of a multi-byte character,
you get a decoding error...

A slightly more complicated approach would be to read
sizehint bytes and then while the result doesn't end in a
newline, read one more byte and decode again.  When sizehint
is large enough, doing byte-at-a-time reading of the last
half-line shouldn't be that bad for performance.  No, I
don't have a patch.

Is there a way to differentiate between "the byte string
ends with an incomplete multi-byte character" and "the byte
string contains an invalid sequence of bytes"?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 10:51

Message:
Logged In: YES 
user_id=38388

Good catch. I must have overread the "whole lines" bit :-)

In that case, it's probably best to have .readlines() ignore
the sizehint argument altogether. An efficient implementation
is hard to do since the line breaking is not done at C level,
but after the data has been read.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-02-26 02:14

Message:
Logged In: YES 
user_id=2772

To me, the phrase "*whole lines* totalling approximately
sizehint" means that no item from readlines(sizehint) will
be an incomplete line.  I don't understand why this
requirement isn't clearly indicated to you by the text you
included in your comments.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 00:04

Message:
Logged In: YES 
user_id=38388

It's hard to say whether this is a bug or not. The sizehint
argument is not well documented and the way you use it
does not look a proper way to use it.

>From the docs:
""""
f the optional sizehint argument is present, instead of
reading up to EOF, whole lines totalling approximately
sizehint bytes (possibly after rounding up to an internal
buffer size) are read. 
""""

In your example the underlying open() implementation 
seems to round up the sizehint value to include the whole
line, while the codec.open() version will only read sizehint
bytes without any rounding (see the codecs.py 
implementation).


----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2003-11-18 18:28

Message:
Logged In: YES 
user_id=2772

The script triggers the assertion error using at least
python 2.3.2 (locally compiled) and python 2.2.2 (redhat 9 RPM)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 10:26:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 10:28:41 2004
Subject: [ python-Bugs-844561 ] codecs.open().readlines(sizehint) bug
Message-ID: <E1AwNOy-0006jg-00@sc8-sf-web1.sourceforge.net>

Bugs item #844561, was opened at 2003-11-18 18:22
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470

Category: Unicode
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Jeff Epler (jepler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: codecs.open().readlines(sizehint) bug

Initial Comment:
codecs.open().readlines(sizehint) can return truncated
lines.  The attached script, which uses
readlines(sizehint) to count the number of lines in a
file, demonstrates the problem.  Correct output would
be 1000 in both cases, but different values are
returned depending on sizehint because of the truncated
lines.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 16:26

Message:
Logged In: YES 
user_id=38388

Fixed in CVS.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 16:20

Message:
Logged In: YES 
user_id=38388

Ok, I'll fix codecs.py to ignore the sizehint argument then
(should not break any code; at worst it might cause problems
with MemoryOverflows).

To answer your question: whether a byte string is incomplete
or in error depends on the encoding and only the codec can
decide what to do. While the codecs do differentiate and the
error callback logic could be used to work out a correct
solution, this would require a lot of work.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-02-26 15:50

Message:
Logged In: YES 
user_id=2772

Ignoring sizehint and reading the whole file is probably
better than truncating lines.  This change would also fix
another bug I realized exists in codecs readlines(sizehint)
currently: if it reads only part of a multi-byte character,
you get a decoding error...

A slightly more complicated approach would be to read
sizehint bytes and then while the result doesn't end in a
newline, read one more byte and decode again.  When sizehint
is large enough, doing byte-at-a-time reading of the last
half-line shouldn't be that bad for performance.  No, I
don't have a patch.

Is there a way to differentiate between "the byte string
ends with an incomplete multi-byte character" and "the byte
string contains an invalid sequence of bytes"?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 10:51

Message:
Logged In: YES 
user_id=38388

Good catch. I must have overread the "whole lines" bit :-)

In that case, it's probably best to have .readlines() ignore
the sizehint argument altogether. An efficient implementation
is hard to do since the line breaking is not done at C level,
but after the data has been read.

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-02-26 02:14

Message:
Logged In: YES 
user_id=2772

To me, the phrase "*whole lines* totalling approximately
sizehint" means that no item from readlines(sizehint) will
be an incomplete line.  I don't understand why this
requirement isn't clearly indicated to you by the text you
included in your comments.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 00:04

Message:
Logged In: YES 
user_id=38388

It's hard to say whether this is a bug or not. The sizehint
argument is not well documented and the way you use it
does not look a proper way to use it.

>From the docs:
""""
f the optional sizehint argument is present, instead of
reading up to EOF, whole lines totalling approximately
sizehint bytes (possibly after rounding up to an internal
buffer size) are read. 
""""

In your example the underlying open() implementation 
seems to round up the sizehint value to include the whole
line, while the codec.open() version will only read sizehint
bytes without any rounding (see the codecs.py 
implementation).


----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2003-11-18 18:28

Message:
Logged In: YES 
user_id=2772

The script triggers the assertion error using at least
python 2.3.2 (locally compiled) and python 2.2.2 (redhat 9 RPM)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 11:28:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 11:30:27 2004
Subject: [ python-Bugs-903483 ] cPickle/pickle incompatibility
Message-ID: <E1AwOMl-00033q-00@sc8-sf-web3.sourceforge.net>

Bugs item #903483, was opened at 2004-02-24 15:59
Message generated for change (Settings changed) made by tismer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903483&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christian Tismer (tismer)
Assigned to: Christian Tismer (tismer)
Summary: cPickle/pickle incompatibility

Initial Comment:
Pickling of functions:
pickle.py first tries a save_global.
If that doesn&#039;t work, it tries a save_reduce.
This fallback allows to register pickling of local
functions
via copy_reg.

cPickle doesn&#039;t do that.
This bug/omission exists since Python 2.3. 

Solution:
A simple patch allows cPickle to fall back to reduce as
well.

Range:
I think this patch should be applied back to Python 2.3.


----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2004-02-24 16:06

Message:
Logged In: YES 
user_id=105700

Here the obvious patch:

cvs -z9 diff -u -wb cPickle.c (in directory
D:\cvsdown\python\dist\src\Modules\)
Index: cPickle.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/cPickle.c,v
retrieving revision 2.148
diff -u -w -b -r2.148 cPickle.c
--- cPickle.c    12 Oct 2003 19:09:36 -0000    2.148
+++ cPickle.c    24 Feb 2004 14:28:34 -0000
@@ -2418,6 +2418,11 @@
     case 'f':
         if (type == &PyFunction_Type) {
             res = save_global(self, args, NULL);
+            if (res && PyErr_ExceptionMatches(PickleError)) {
+                /* fall back to reduce */
+                       PyErr_Clear();
+                       break;
+            }
             goto finally;
         }
     break;


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903483&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 12:28:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 12:30:46 2004
Subject: [ python-Feature Requests-900502 ] bundlebuilder: some way to add
	non-py files in packages
Message-ID: <E1AwPJ1-0006jn-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #900502, was opened at 2004-02-19 10:30
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900502&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bundlebuilder: some way to add non-py files in packages

Initial Comment:
I would like some way to load non-python code that is 
contained in packages. In other words, suppose I have:
maindir/
  helpdir/
    __init__.py
    index.html
    ...other python code and help files

I&#039;d like some way to specify that the code in helpdir be 
loaded as code (compiled and the source discarded) but that 
the other files also be copied over. Presently includePackages 
only copies over python files.

The best workaround I&#039;ve found so far is to specify the 
package in two separate arguments to buildapp: 
includePackages and resources. That copies everything 
(including the python source) and also compiles everything, 
so one ends up with both .py and .pyc files. I then look in 
that folder and discard the python source after 
bundlebuilder is finished. (I suppose that step is optional.)

Simply modifying includePackages so it included non-python 
files is my first thought. It might occasionally include stuff 
that wasn&#039;t wanted, but aside from on occasional README 
or something, I doubt it would amount to anything 
significant in most cases.

----------------------------------------------------------------------

>Comment By: Russell Owen (reowen)
Date: 2004-02-26 09:28

Message:
Logged In: YES 
user_id=431773

Because putting resource files in sub-packages makes them very easy to find. For example:
TUI/
  __init__.py
  Help/
    __init__.py
    index.html, etc.

(TUI is on the python path)
import os, TUI.Help
helpdir = os.path.dirname(TUI.Help.__file__)

This is all the more useful when one's main .py file gets moved by bundlebuilder from within (in my case) TUI up one level.

Also, many folks may be trying to convert existing code (I was) that uses this trick. It seems a shame to have to rewrite it. Of course one need not actually rewrite it, but a bundlebuilder script becomes quite messy for such code without this requested feature.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 18:37

Message:
Logged In: YES 
user_id=139309

why not keep your code and data in separate folders?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900502&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 12:33:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 12:36:07 2004
Subject: [ python-Feature Requests-900514 ] bundlebuilder: easily keep main
	routine in orig location
Message-ID: <E1AwPOA-00078j-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #900514, was opened at 2004-02-19 10:44
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900514&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bundlebuilder: easily keep main routine in orig location

Initial Comment:
I&#039;d like to ask that bundlebuilder.py keep the main routine in 
its original location with respect to whatever package it 
appears in, i.e. if the app&#039;s main is
MyPgk/Main.py

then the code is put in MyPkg:
Contents/Resources/Modules.zip
      /MyPkg/Main.py

or if no zipping is done:
Contents/Resources/MyPkg/Main.py

I fear this may be too difficult to be worth the work, but I 
wasn&#039;t sure and felt it better to ask.

The issue is (as in my 2 previous bundlebuilder requests) 
making it easier to write cross-platform code. If one carefully 
develops code for Mac then one can easily organize it such 
that it fits perfectly within bundlebuilder&#039;s assumptions.

But in my case I wrote code to run under unix first, then 
tried to get a working double-clickable Mac app, and it was a 
a surprising amount of work. Among other things, I had to 
rewrite my Main.py so it could be moved relative to its 
package (not a really big deal, but surprising). The other 
requests would simplify or eliminate cleanup work I do after 
the bundle is built.

----------------------------------------------------------------------

>Comment By: Russell Owen (reowen)
Date: 2004-02-26 09:33

Message:
Logged In: YES 
user_id=431773

I'm afraid I don't follow your reply. My point was that bundlebuilder could always write some kind of executable whose job was to import and execute the user's main .py script.

This has several advantages:
- The user's main code gets compiled; presumably this makes it run faster
- The user's main code never has to be moved

I suspect the bundlebuilder option "executable" may even have been designed for this task, but I've not yet figured out how to use it; I did try it a bit, but bb still required a "mainprogram" so I realized I hadn't a clue what I was doing and gave up on it.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 18:39

Message:
Logged In: YES 
user_id=139309

This doesn't *really* make sense.. is it too hard to have a bootstrap 
script that imports and executes this?  Isn't that what you would have on 
other platforms?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900514&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 12:36:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 12:38:52 2004
Subject: [ python-Feature Requests-900502 ] bundlebuilder: some way to add
	non-py files in packages
Message-ID: <E1AwPQz-0007kp-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #900502, was opened at 2004-02-19 13:30
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900502&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bundlebuilder: some way to add non-py files in packages

Initial Comment:
I would like some way to load non-python code that is 
contained in packages. In other words, suppose I have:
maindir/
  helpdir/
    __init__.py
    index.html
    ...other python code and help files

I&#039;d like some way to specify that the code in helpdir be 
loaded as code (compiled and the source discarded) but that 
the other files also be copied over. Presently includePackages 
only copies over python files.

The best workaround I&#039;ve found so far is to specify the 
package in two separate arguments to buildapp: 
includePackages and resources. That copies everything 
(including the python source) and also compiles everything, 
so one ends up with both .py and .pyc files. I then look in 
that folder and discard the python source after 
bundlebuilder is finished. (I suppose that step is optional.)

Simply modifying includePackages so it included non-python 
files is my first thought. It might occasionally include stuff 
that wasn&#039;t wanted, but aside from on occasional README 
or something, I doubt it would amount to anything 
significant in most cases.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-26 12:36

Message:
Logged In: YES 
user_id=139309

Yes, there is plenty of existing code that uses this idiom.. but it's awfully 
hard for bundlebuilder to detect it automatically.  The real solution (that 
doesn't require grotesque intelligence in bundlebuilder) is to propose a 
new extensible idiom for loading resources, which is currently being 
discussed on pythonmac-sig and pygame-users under the subject "python 
+ pygame of OSX".

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-26 12:28

Message:
Logged In: YES 
user_id=431773

Because putting resource files in sub-packages makes them very easy to find. For example:
TUI/
  __init__.py
  Help/
    __init__.py
    index.html, etc.

(TUI is on the python path)
import os, TUI.Help
helpdir = os.path.dirname(TUI.Help.__file__)

This is all the more useful when one's main .py file gets moved by bundlebuilder from within (in my case) TUI up one level.

Also, many folks may be trying to convert existing code (I was) that uses this trick. It seems a shame to have to rewrite it. Of course one need not actually rewrite it, but a bundlebuilder script becomes quite messy for such code without this requested feature.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 21:37

Message:
Logged In: YES 
user_id=139309

why not keep your code and data in separate folders?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900502&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 12:43:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 12:45:55 2004
Subject: [ python-Feature Requests-900514 ] bundlebuilder: easily keep main
	routine in orig location
Message-ID: <E1AwPXh-0002h9-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #900514, was opened at 2004-02-19 13:44
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900514&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bundlebuilder: easily keep main routine in orig location

Initial Comment:
I&#039;d like to ask that bundlebuilder.py keep the main routine in 
its original location with respect to whatever package it 
appears in, i.e. if the app&#039;s main is
MyPgk/Main.py

then the code is put in MyPkg:
Contents/Resources/Modules.zip
      /MyPkg/Main.py

or if no zipping is done:
Contents/Resources/MyPkg/Main.py

I fear this may be too difficult to be worth the work, but I 
wasn&#039;t sure and felt it better to ask.

The issue is (as in my 2 previous bundlebuilder requests) 
making it easier to write cross-platform code. If one carefully 
develops code for Mac then one can easily organize it such 
that it fits perfectly within bundlebuilder&#039;s assumptions.

But in my case I wrote code to run under unix first, then 
tried to get a working double-clickable Mac app, and it was a 
a surprising amount of work. Among other things, I had to 
rewrite my Main.py so it could be moved relative to its 
package (not a really big deal, but surprising). The other 
requests would simplify or eliminate cleanup work I do after 
the bundle is built.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-26 12:43

Message:
Logged In: YES 
user_id=139309

I don't agree with either of your advantages.
- bundlebuilder could compile the "main code" as-is, it just doesn't
- never has to be moved, in exchange for importing foo.bar as 
__main__?  No thanks.

"executable" is for something else.  "mainprogram" is exactly what it 
says it is, it's a program, not a module-inside-a-package-that-should-be-
imported-as-__main__.  Perhaps there could be a 
"writemeamainprogram" argument where you would specify something 
like "foo.bar:main" where foo.bar is the module and main is the 
function.. but then how would you decide which idiom it should be called 
with (sys.argv[1:], sys.argv, no arguments, etc.).

It's not hard to make a two-line program that does what you need it to 
and use that as the mainprogram.. I think this use case is just too 
specific to the style of your single application.  I *always* see the 
separate-main-program idiom used that imports something and calls 
some function, I have *never* seen people symlink something in /usr/
local/bin to something in site-packages.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-26 12:33

Message:
Logged In: YES 
user_id=431773

I'm afraid I don't follow your reply. My point was that bundlebuilder could always write some kind of executable whose job was to import and execute the user's main .py script.

This has several advantages:
- The user's main code gets compiled; presumably this makes it run faster
- The user's main code never has to be moved

I suspect the bundlebuilder option "executable" may even have been designed for this task, but I've not yet figured out how to use it; I did try it a bit, but bb still required a "mainprogram" so I realized I hadn't a clue what I was doing and gave up on it.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 21:39

Message:
Logged In: YES 
user_id=139309

This doesn't *really* make sense.. is it too hard to have a bootstrap 
script that imports and executes this?  Isn't that what you would have on 
other platforms?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900514&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 12:23:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 12:57:01 2004
Subject: [ python-Bugs-854823 ] Python-2.3.3c1,
	Solaris 2.7: socketmodule does not compile
Message-ID: <E1AwPDz-0000zU-00@sc8-sf-web4.sourceforge.net>

Bugs item #854823, was opened at 2003-12-05 09:01
Message generated for change (Comment added) made by sfiedler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=854823&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Falko Sauermann (fsm2761)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.3.3c1, Solaris 2.7: socketmodule does not compile

Initial Comment:
Compiling Python-2.3.3c1 on Solaris 2.7 with gcc 2.95.3
gave me two errors:

socketmodule.c:2975: `AF_INET6&#039; undeclared (first use
in this function)

socketmodule.c:3019: `INET_ADDRSTRLEN&#039; undeclared
(first use in this function)

The first problem was already reported for Solaris 2.7
with SunPro cc (see item 814613) but is also true for
Solaris 2.7 with gcc.

The real problem is that AF_INET6 is used when
ENABLE_IPV6 is undefined. I believe this must fail for
any system where IPV6 is not avalilable.

The second problem was already reported for Irix (see
item 818490) but is also true for Solaris 2.7. The
solution for Irix is also valid for Solaris. If I
change socketmodule.c line 204 to:

#if (defined(__sgi) || defined(sun)) &&
!defined(INET_ADDRSTRLEN)

the error is gone.

----------------------------------------------------------------------

Comment By: Stephan A. Terre (sfiedler)
Date: 2004-02-26 10:23

Message:
Logged In: YES 
user_id=246063

I think it's worth noting that the preprocessor directive
near line 2975 is #ifndef , whereas all other preprocessor
directives in the file that refer to the IPV6 symbol are
#ifdef . In other words, it looks like just that one
directive is a typo. Changing #ifndef to #ifdef fixes it for me.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=854823&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 12:55:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 12:57:27 2004
Subject: [ python-Feature Requests-900502 ] bundlebuilder: some way to add
	non-py files in packages
Message-ID: <E1AwPiy-0000kJ-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #900502, was opened at 2004-02-19 10:30
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900502&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bundlebuilder: some way to add non-py files in packages

Initial Comment:
I would like some way to load non-python code that is 
contained in packages. In other words, suppose I have:
maindir/
  helpdir/
    __init__.py
    index.html
    ...other python code and help files

I&#039;d like some way to specify that the code in helpdir be 
loaded as code (compiled and the source discarded) but that 
the other files also be copied over. Presently includePackages 
only copies over python files.

The best workaround I&#039;ve found so far is to specify the 
package in two separate arguments to buildapp: 
includePackages and resources. That copies everything 
(including the python source) and also compiles everything, 
so one ends up with both .py and .pyc files. I then look in 
that folder and discard the python source after 
bundlebuilder is finished. (I suppose that step is optional.)

Simply modifying includePackages so it included non-python 
files is my first thought. It might occasionally include stuff 
that wasn&#039;t wanted, but aside from on occasional README 
or something, I doubt it would amount to anything 
significant in most cases.

----------------------------------------------------------------------

>Comment By: Russell Owen (reowen)
Date: 2004-02-26 09:55

Message:
Logged In: YES 
user_id=431773

I completely agree that bb should not have to detect this stuff automatically. I was simply hoping that something such as one of the following could be done:

- includePackages could be modified to include non-python files
- A new option could be added, one similar to includePackages that did everything includePackages does plus also includes all non-python files in the specified packages.


----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-26 09:36

Message:
Logged In: YES 
user_id=139309

Yes, there is plenty of existing code that uses this idiom.. but it's awfully 
hard for bundlebuilder to detect it automatically.  The real solution (that 
doesn't require grotesque intelligence in bundlebuilder) is to propose a 
new extensible idiom for loading resources, which is currently being 
discussed on pythonmac-sig and pygame-users under the subject "python 
+ pygame of OSX".

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-26 09:28

Message:
Logged In: YES 
user_id=431773

Because putting resource files in sub-packages makes them very easy to find. For example:
TUI/
  __init__.py
  Help/
    __init__.py
    index.html, etc.

(TUI is on the python path)
import os, TUI.Help
helpdir = os.path.dirname(TUI.Help.__file__)

This is all the more useful when one's main .py file gets moved by bundlebuilder from within (in my case) TUI up one level.

Also, many folks may be trying to convert existing code (I was) that uses this trick. It seems a shame to have to rewrite it. Of course one need not actually rewrite it, but a bundlebuilder script becomes quite messy for such code without this requested feature.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 18:37

Message:
Logged In: YES 
user_id=139309

why not keep your code and data in separate folders?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900502&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 13:03:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 13:05:50 2004
Subject: [ python-Feature Requests-900514 ] bundlebuilder: easily keep main
	routine in orig location
Message-ID: <E1AwPr4-0001Pg-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #900514, was opened at 2004-02-19 10:44
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900514&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bundlebuilder: easily keep main routine in orig location

Initial Comment:
I&#039;d like to ask that bundlebuilder.py keep the main routine in 
its original location with respect to whatever package it 
appears in, i.e. if the app&#039;s main is
MyPgk/Main.py

then the code is put in MyPkg:
Contents/Resources/Modules.zip
      /MyPkg/Main.py

or if no zipping is done:
Contents/Resources/MyPkg/Main.py

I fear this may be too difficult to be worth the work, but I 
wasn&#039;t sure and felt it better to ask.

The issue is (as in my 2 previous bundlebuilder requests) 
making it easier to write cross-platform code. If one carefully 
develops code for Mac then one can easily organize it such 
that it fits perfectly within bundlebuilder&#039;s assumptions.

But in my case I wrote code to run under unix first, then 
tried to get a working double-clickable Mac app, and it was a 
a surprising amount of work. Among other things, I had to 
rewrite my Main.py so it could be moved relative to its 
package (not a really big deal, but surprising). The other 
requests would simplify or eliminate cleanup work I do after 
the bundle is built.

----------------------------------------------------------------------

>Comment By: Russell Owen (reowen)
Date: 2004-02-26 10:03

Message:
Logged In: YES 
user_id=431773

I think this discussion is getting off track.

It is certainly reasonable (or at least I hope it is) to write
TUI/
  Main.py
and expect unix users to execute Main.py, for example:
alias tui <tui_root>/TUI/Main.py

The problem comes when bundlebuilder helpfully pulls Main.py out of TUI and puts up up at the main level. It seems an odd arrangement of files to me -- I'd much rather stuff all my app's files into a directory and make that a package (to reduce the danger of namespace collisions).

I really don't see the importing issue coming up here. I was hoping bundlebuilder would simply execute the file TUI/Main.py without moving it. It doesn't need to import anything, it just needs to execute the file.

Anyway, I do agree it's not that hard to work around. It just seems a shame that bundlebuilder moves files around without being asked. Once one realizes what is going on, one can figure out workarounds -- such as making the main file movable or writing a stupid 2-line extra script to call the main file.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-26 09:43

Message:
Logged In: YES 
user_id=139309

I don't agree with either of your advantages.
- bundlebuilder could compile the "main code" as-is, it just doesn't
- never has to be moved, in exchange for importing foo.bar as 
__main__?  No thanks.

"executable" is for something else.  "mainprogram" is exactly what it 
says it is, it's a program, not a module-inside-a-package-that-should-be-
imported-as-__main__.  Perhaps there could be a 
"writemeamainprogram" argument where you would specify something 
like "foo.bar:main" where foo.bar is the module and main is the 
function.. but then how would you decide which idiom it should be called 
with (sys.argv[1:], sys.argv, no arguments, etc.).

It's not hard to make a two-line program that does what you need it to 
and use that as the mainprogram.. I think this use case is just too 
specific to the style of your single application.  I *always* see the 
separate-main-program idiom used that imports something and calls 
some function, I have *never* seen people symlink something in /usr/
local/bin to something in site-packages.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-26 09:33

Message:
Logged In: YES 
user_id=431773

I'm afraid I don't follow your reply. My point was that bundlebuilder could always write some kind of executable whose job was to import and execute the user's main .py script.

This has several advantages:
- The user's main code gets compiled; presumably this makes it run faster
- The user's main code never has to be moved

I suspect the bundlebuilder option "executable" may even have been designed for this task, but I've not yet figured out how to use it; I did try it a bit, but bb still required a "mainprogram" so I realized I hadn't a clue what I was doing and gave up on it.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 18:39

Message:
Logged In: YES 
user_id=139309

This doesn't *really* make sense.. is it too hard to have a bootstrap 
script that imports and executes this?  Isn't that what you would have on 
other platforms?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900514&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 13:11:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 13:14:27 2004
Subject: [ python-Feature Requests-900514 ] bundlebuilder: easily keep main
	routine in orig location
Message-ID: <E1AwPzJ-0004kJ-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #900514, was opened at 2004-02-19 13:44
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900514&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: bundlebuilder: easily keep main routine in orig location

Initial Comment:
I&#039;d like to ask that bundlebuilder.py keep the main routine in 
its original location with respect to whatever package it 
appears in, i.e. if the app&#039;s main is
MyPgk/Main.py

then the code is put in MyPkg:
Contents/Resources/Modules.zip
      /MyPkg/Main.py

or if no zipping is done:
Contents/Resources/MyPkg/Main.py

I fear this may be too difficult to be worth the work, but I 
wasn&#039;t sure and felt it better to ask.

The issue is (as in my 2 previous bundlebuilder requests) 
making it easier to write cross-platform code. If one carefully 
develops code for Mac then one can easily organize it such 
that it fits perfectly within bundlebuilder&#039;s assumptions.

But in my case I wrote code to run under unix first, then 
tried to get a working double-clickable Mac app, and it was a 
a surprising amount of work. Among other things, I had to 
rewrite my Main.py so it could be moved relative to its 
package (not a really big deal, but surprising). The other 
requests would simplify or eliminate cleanup work I do after 
the bundle is built.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-26 13:11

Message:
Logged In: YES 
user_id=139309

The problem is that it doesn't know that the path TUI is important when 
you give it a mainprogram; mainprogram can be any path.  When it does 
modulefinder on your mainprogram, it sees it as __main__, not as 
TUI.Main, as it should.

If you follow the standard unix way of doing scripts, which is writing a 
script "tui" that imports TUI.Main and calls whatever needs to be called, 
then everything will work just fine.  That's what mainprogram is.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-26 13:03

Message:
Logged In: YES 
user_id=431773

I think this discussion is getting off track.

It is certainly reasonable (or at least I hope it is) to write
TUI/
  Main.py
and expect unix users to execute Main.py, for example:
alias tui <tui_root>/TUI/Main.py

The problem comes when bundlebuilder helpfully pulls Main.py out of TUI and puts up up at the main level. It seems an odd arrangement of files to me -- I'd much rather stuff all my app's files into a directory and make that a package (to reduce the danger of namespace collisions).

I really don't see the importing issue coming up here. I was hoping bundlebuilder would simply execute the file TUI/Main.py without moving it. It doesn't need to import anything, it just needs to execute the file.

Anyway, I do agree it's not that hard to work around. It just seems a shame that bundlebuilder moves files around without being asked. Once one realizes what is going on, one can figure out workarounds -- such as making the main file movable or writing a stupid 2-line extra script to call the main file.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-26 12:43

Message:
Logged In: YES 
user_id=139309

I don't agree with either of your advantages.
- bundlebuilder could compile the "main code" as-is, it just doesn't
- never has to be moved, in exchange for importing foo.bar as 
__main__?  No thanks.

"executable" is for something else.  "mainprogram" is exactly what it 
says it is, it's a program, not a module-inside-a-package-that-should-be-
imported-as-__main__.  Perhaps there could be a 
"writemeamainprogram" argument where you would specify something 
like "foo.bar:main" where foo.bar is the module and main is the 
function.. but then how would you decide which idiom it should be called 
with (sys.argv[1:], sys.argv, no arguments, etc.).

It's not hard to make a two-line program that does what you need it to 
and use that as the mainprogram.. I think this use case is just too 
specific to the style of your single application.  I *always* see the 
separate-main-program idiom used that imports something and calls 
some function, I have *never* seen people symlink something in /usr/
local/bin to something in site-packages.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2004-02-26 12:33

Message:
Logged In: YES 
user_id=431773

I'm afraid I don't follow your reply. My point was that bundlebuilder could always write some kind of executable whose job was to import and execute the user's main .py script.

This has several advantages:
- The user's main code gets compiled; presumably this makes it run faster
- The user's main code never has to be moved

I suspect the bundlebuilder option "executable" may even have been designed for this task, but I've not yet figured out how to use it; I did try it a bit, but bb still required a "mainprogram" so I realized I hadn't a clue what I was doing and gave up on it.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-02-25 21:39

Message:
Logged In: YES 
user_id=139309

This doesn't *really* make sense.. is it too hard to have a bootstrap 
script that imports and executes this?  Isn't that what you would have on 
other platforms?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=900514&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 16:19:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 16:32:00 2004
Subject: [ python-Bugs-905389 ] str.join() intercepts TypeError raised by
	iterator
Message-ID: <E1AwSv7-0003Ag-00@sc8-sf-web1.sourceforge.net>

Bugs item #905389, was opened at 2004-02-26 13:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905389&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Lenard Lindstrom (kermode)
Assigned to: Nobody/Anonymous (nobody)
Summary: str.join() intercepts TypeError raised by iterator

Initial Comment:
For str.join(), if it is passed an iterator and that 
iterator raises a TypeError, that exception is caught 
by the join method and replaced by its own 
TypeError exception. SyntaxError and IndexError 
exceptions are uneffected.

Example:

Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC 
v.1200 32 bit (Intel)] on win32
...
IDLE 1.0.2      
>>> def gen(n):
	if not isinstance(n, int):
		raise TypeError, "gen() TypeError"
	if n<0:
		raise IndexError,  "gen() 
IndexError"
	for i in range(n):
		yield str(i)

		
>>> &#039;&#039;.join(gen(5))
&#039;01234&#039;
>>> &#039;&#039;.join(gen(-1))

Traceback (most recent call last):
  File "<pyshell#9>", line 1, in -toplevel-
    &#039;&#039;.join(gen(-1))
  File "<pyshell#7>", line 5, in gen
    raise IndexError, "gen() IndexError"
IndexError: gen() IndexError
>>> &#039;&#039;.join(gen(None))

Traceback (most recent call last):
  File "<pyshell#10>", line 1, in -toplevel-
    &#039;&#039;.join(gen(None))
TypeError: sequence expected, generator found
>>> 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905389&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 19:55:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 19:58:19 2004
Subject: [ python-Bugs-901285 ] random.randint fails for some ranges
Message-ID: <E1AwWII-0005VL-00@sc8-sf-web3.sourceforge.net>

Bugs item #901285, was opened at 2004-02-20 14:27
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901285&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: random.randint fails for some ranges

Initial Comment:
I want a random 32-bit int and do it the obvious way:

lowest, highest = int(-2**31), int(2**31-1)
r = random.randint(lowest, highest)

random.randint throws an exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/random.py", line 349, in randint
    return self.randrange(a, b+1)
  File "/usr/lib/python2.2/random.py", line 328, in
randrange
    raise ValueError, "empty range for randrange()"
ValueError: empty range for randrange()


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-21 03:17

Message:
Logged In: YES 
user_id=80475

This has been fixed for Py2.3.3 and 2.4 as a result of the
automatic conversion between ints and longs.

In 2.2, it is still possible, but the call to int() inside
random.randrange() would be have to be changed to math.floor() 
which can handle the full range.  As the comments indicate,
this was not worth a performance hit.

As a workaround, generate two 16 bit integers and then join
them with (a << 16) | b.  This ought to work for practical
purposes; however, the underlying generator may not be
strong enough to make this a theoretically reliable
transform (i.e. it may dramatically shorten the period of
the composite generator).

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-02-21 03:17

Message:
Logged In: YES 
user_id=72053

Oops, ignore previous comment, it was added to the wrong
bug.  Sorry.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-02-21 03:16

Message:
Logged In: YES 
user_id=72053

It says "; current system time is also used to initialize
the generator when the module is first imported. "  That
sugests that the module is passing the current time to the
generator, rather than that the generator is initializing
itself with the current time.

Proposed new wording: ".  When a new generator is
instantiated, its inititialization method calls the seed
operation with a parameter of None.  The seed method then
uses the current time to initialize the generator as
described above.  If you subclass Random, your seed
operation can use some different method to create a default
seed on being initialized with None."

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=901285&group_id=5470

From noreply at sourceforge.net  Thu Feb 26 19:58:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Feb 26 20:00:56 2004
Subject: [ python-Bugs-905389 ] str.join() intercepts TypeError raised by
	iterator
Message-ID: <E1AwWKi-0000Uv-00@sc8-sf-web4.sourceforge.net>

Bugs item #905389, was opened at 2004-02-26 16:19
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905389&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Lenard Lindstrom (kermode)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: str.join() intercepts TypeError raised by iterator

Initial Comment:
For str.join(), if it is passed an iterator and that 
iterator raises a TypeError, that exception is caught 
by the join method and replaced by its own 
TypeError exception. SyntaxError and IndexError 
exceptions are uneffected.

Example:

Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC 
v.1200 32 bit (Intel)] on win32
...
IDLE 1.0.2      
>>> def gen(n):
	if not isinstance(n, int):
		raise TypeError, "gen() TypeError"
	if n<0:
		raise IndexError,  "gen() 
IndexError"
	for i in range(n):
		yield str(i)

		
>>> &#039;&#039;.join(gen(5))
&#039;01234&#039;
>>> &#039;&#039;.join(gen(-1))

Traceback (most recent call last):
  File "<pyshell#9>", line 1, in -toplevel-
    &#039;&#039;.join(gen(-1))
  File "<pyshell#7>", line 5, in gen
    raise IndexError, "gen() IndexError"
IndexError: gen() IndexError
>>> &#039;&#039;.join(gen(None))

Traceback (most recent call last):
  File "<pyshell#10>", line 1, in -toplevel-
    &#039;&#039;.join(gen(None))
TypeError: sequence expected, generator found
>>> 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905389&group_id=5470

From noreply at sourceforge.net  Fri Feb 27 02:35:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 27 02:37:49 2004
Subject: [ python-Bugs-791542 ] test_threading
Message-ID: <E1AwcWf-0008QB-00@sc8-sf-web2.sourceforge.net>

Bugs item #791542, was opened at 2003-08-19 14:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791542&group_id=5470

Category: Build
Group: Python 2.2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Shawn Leard (sleard1)
Assigned to: Brett Cannon (bcannon)
Summary: test_threading

Initial Comment:

Due the problems reported with version 2.3 I thought I
would give version 2.2.3 a shot. The problem I am
having here is no matter what switches I pass configure
to disable threading it still tries to test them and as
a result the make test fails.

168 tests OK.
1 test failed:
    test_threading
24 tests skipped:
    test_al test_asynchat test_bsddb test_cd test_cl
test_curses
    test_dl test_email_codecs test_fork1 test_gl
test_imgfile
    test_linuxaudiodev test_minidom test_openpty
test_pyexpat
    test_queue test_sax test_socket_ssl
test_socketserver test_thread
    test_threaded_import test_threadedtempfile test_winreg
    test_winsound

--------

./configure --prefix=/usr/local --with-gnu-ld
--with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld
--enable-nls   --with-included-gettext --with-fpectl
--with-threads=no --without-threads --disable-threads
--with-gnu-as

--------

mars$ /files/local/src/Python-2.2.3/python
test_threading.py
Traceback (most recent call last):
  File "test_threading.py", line 7, in ?
    import threading
  File
"/files/local/src/Python-2.2.3/Lib/threading.py", line
5, in ?
    import thread
ImportError: No module named thread


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-02-26 23:35

Message:
Logged In: YES 
user_id=357491

OK, I didn't get this with CVS Python 2.3 so I am closing this as invalid.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 13:24

Message:
Logged In: YES 
user_id=357491

That's fine, Shawn, but I still feel the need to look into it.  There is no 
reason for that to be happening.  I feel I should at least verify that this 
doesn't happen on my box because if it does there is a bug somewhere.

----------------------------------------------------------------------

Comment By: Shawn Leard (sleard1)
Date: 2004-02-17 05:51

Message:
Logged In: YES 
user_id=328879



Brett,

I am going to close this because the box I had was
redeployed and I have no longer had this problem.

Best Regards,

Shawn


----------------------------------------------------------------------

Comment By: Shawn Leard (sleard1)
Date: 2003-09-08 13:00

Message:
Logged In: YES 
user_id=328879



I will give this a shot and get back to you.



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-09-04 18:53

Message:
Logged In: YES 
user_id=357491

In order to better debug this, can you state what the line says 
when test_threading fails; e.g., "test_sunaudiodev skipped -- ..."?

The test will be run regardless of whether you compiled with 
threads or not, but it should be listed as a skip instead of a 
failure.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791542&group_id=5470

From noreply at sourceforge.net  Fri Feb 27 04:54:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 27 04:57:08 2004
Subject: [ python-Bugs-798058 ] IDLE / PyOS_InputHook
Message-ID: <E1AwehO-0006Xk-00@sc8-sf-web2.sourceforge.net>

Bugs item #798058, was opened at 2003-08-31 17:45
Message generated for change (Settings changed) made by mdehoon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798058&group_id=5470

>Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michiel de Hoon (mdehoon)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE / PyOS_InputHook

Initial Comment:
[This bug report is a follow-up of a discussion with
Matthew Cowler of help@python]

I noticed an inconsistency with the usage of the
PyOS_InputHook variable between Python 2.3&#039;s IDLE and
Python run from the (DOS or linux) command prompt. This
problem does not occur with earlier versions of Python.
First I will describe the problem, then why it is
important to me.

The PyOS_InputHook variable can be used to install a
callback function that gets called periodically (via
readline&#039;s rl_event_hook) when Python is waiting for
terminal input. When Python is run as a terminal
application (from the DOS or linux command prompt),
PyOS_InputHook is NULL initially. Python C extension
modules can set PyOS_InputHook to a function which is
to be called periodically. This works with Python 2.3
and older versions.

In Python 2.2, IDLE makes use of the PyOS_InputHook
variable, presumably to get messages delivered to the
Tkinter window. Python C extension modules that are
loaded from IDLE find that PyOS_InputHook is not NULL,
and therefore cannot specify a different callback
function via PyOS_InputHook, as that would freeze the
Tkinter window.

Now on Python 2.2, in practice that is not a problem.
IDLE in Python 2.2 runs in a single thread. This thread
contains a message loop (probably hidden in the Tk
library) that takes care of the messages destined for
the Tk window. If we open an additional (non-Tk) window
from our C extension module, then its messages also get
processed by Tk&#039;s message loop as it is running in the
same thread. So we don&#039;t need an additional message
loop for our non-Tk window, and we don&#039;t need to change
PyOS_InputHook.

In Python 2.3, IDLE works differently, as it talks to
its interactive interpreter on the TCP/IP loopback
interface and does not make use of PyOS_InputHook. If I
import my C extension module from IDLE, it shows that
PyOS_InputHook is NULL. In addition, multithreading is
now used, with three threads on Windows and two on
Linux and Mac OS X. (I am not sure where the additional
thread on Windows is coming from). In particular, the C
extension module and Tk&#039;s message loop are running in
separate threads. So if I open a non-Tk window from my
C extension module, its messages are not handled by
Tk&#039;s message loop.

The solution would be to have a message loop in my C
extension module also, which is how the C extension
module works when Python is run as a terminal
application. As PyOS_InputHook is NULL (both with and
without IDLE) when I import my extension module, I can
point it to a message loop in the extension module
without causing havoc. However, whereas Python without
IDLE calls the function specified by PyOS_InputHook
correctly, Python with IDLE fails to call
PyOS_InputHook. Hence, with IDLE I am stuck in a thread
without a message loop, and no way to provide a message
loop of my own.

If I run IDLE with the "-n" command-line argument to
disable running Python code in a sub-process, there is
only one thread, and I can use that thread&#039;s message
loop without problems.

Would it be possible in Python 2.3 to have
PyOS_InputHook called also if IDLE / Tkinter is
running? I would think that that no longer interferes
with the correct operation of Tkinter / IDLE, as after
importing IDLE, PyOS_InputHook is NULL anyway.


This problem is important to me because of the
Windows-port of Pygist (gist scientific plotting
package for Python), which I codeveloped several months
ago. The core graphics routines of Pygist are written
in C for performance reasons. Pygist does not work with
Python 2.3 with IDLE, while it does work with Python
2.2 with IDLE. There are no problems with Python 2.3
run from the DOS command prompt, nor with PythonWin or
PyShell.

The problem with Python 2.3 with IDLE is that the
graphics window no longer receives its messages. In
usual Windows programs, there is one message loop,
which looks like

while (GetMessage(&msg, NULL, 0, 0))
{ TranslateMessage(&msg);
  DispatchMessage(&msg);
}

In Python 2.2 with IDLE, we use Tk&#039;s message loop to
get messages delivered to the Pygist graphics window.
When running Python 2.2 and Python 2.3 as a terminal
application, we start our own message loop in the C
extension module and point to it using PyOS_InputHook.
With Python 2.3 with IDLE, Tk&#039;s message loop is in a
separate thread, so we can&#039;t use it, while at the same
time PyOS_InputHook is being ignored. Hence Pygist&#039;s
graphics window freezes.

Note that Pygist is different from many other plotting
packages for Python, as it returns to the Python prompt
after opening a graphics Window (allowing you to modify
the window interactively). So the trick is to let both
the Python interpreter and the graphics window receive
their messages.


With regards,

Michiel de Hoon, University of Tokyo.

----------------------------------------------------------------------

Comment By: Michiel de Hoon (mdehoon)
Date: 2004-02-16 10:36

Message:
Logged In: YES 
user_id=488897

I had another look at this and it seems that the problem is
in the Modules/_tkinter.c. If I understand correctly,
tkinter does not use the code in Modules/readline.c, which
contains the call to PyOS_InputHook, and hence
PyOS_InputHook is not being called. Surprisingly, the
tkinter code does set the PyOS_InputHook variable to the
EventHook routine, but this seems to be in vain as
PyOS_InputHook is not being called anyway. I suggest to
resubmit this bug report to the Tkinter category.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798058&group_id=5470

From noreply at sourceforge.net  Fri Feb 27 05:08:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Feb 27 05:10:51 2004
Subject: [ python-Bugs-905737 ] BuildApplet needs to get more
	BuildApplication features
Message-ID: <E1Aweup-0003R7-00@sc8-sf-web4.sourceforge.net>

Bugs item #905737, was opened at 2004-02-27 11:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905737&group_id=5470

Category: Macintosh
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: BuildApplet needs to get more BuildApplication features

Initial Comment:
BuildApplet needs to become a more complete interface to 
bundlebuilder, thereby also getting the function of the old 
BuildApplication, and various intermediate steps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905737&group_id=5470

From noreply at sourceforge.net  Sat Feb 28 06:08:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 28 06:08:44 2004
Subject: [ python-Bugs-906405 ] Build fails on XP
Message-ID: <E1Ax2Kn-0001SK-00@sc8-sf-web2.sourceforge.net>

Bugs item #906405, was opened at 2004-02-28 11:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=906405&group_id=5470

Category: Build
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Con (shrodingersdog)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fails on XP

Initial Comment:
When trying to build the source:

Modules/posixmodule.c fails to build.

I&#039;m running on XP SP1 using 
mingw32-make ver 3.80

Is there any known issues on XP?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=906405&group_id=5470

From noreply at sourceforge.net  Sat Feb 28 11:57:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 28 11:57:22 2004
Subject: [ python-Bugs-897625 ] time.strftime crashes python
Message-ID: <E1Ax7lx-00081C-00@sc8-sf-web2.sourceforge.net>

Bugs item #897625, was opened at 2004-02-15 21:33
Message generated for change (Comment added) made by ashtong
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897625&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Tom Lynn (tlynn)
Assigned to: Brett Cannon (bcannon)
Summary: time.strftime crashes python

Initial Comment:
On Win2k:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Python dumps core.  Is that (ever) expected behaviour?

----------------------------------------------------------------------

Comment By: Graham Ashton (ashtong)
Date: 2004-02-28 16:57

Message:
Logged In: YES 
user_id=263764

Not sure if it's helpful, but here's another data point. I
get the buggy behaviour on 2.3.3 on Gentoo Linux:

ratchet% python
Python 2.3.3 (#1, Jan  6 2004, 09:44:50)
[GCC 3.3.2 20031022 (Gentoo Linux 3.3.2-r2, propolice)] on
linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
Segmentation fault


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-02-21 20:01

Message:
Logged In: YES 
user_id=357491

OK, have a solution coded up, just waiting to hear from Tim on whether a 
change to datetime is okay with him.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 21:59

Message:
Logged In: YES 
user_id=357491

Should be able to deal with this cleanly by modifying gettmarg() to do 
some sanity checks on the values before returning and letting 
time_strftime() at the struct tm that gettmarg() created.

First have to check the ISO C standard, though, to make sure I don't 
overstep my bounds on the sanity checks (or I could just follow our own 
specs, but that would be too easy  =).

----------------------------------------------------------------------

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 20:36

Message:
Logged In: YES 
user_id=304464

On WinXP Home does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\xfcI\xc1w\xf8I\xc1w\xf4I\xc1w\xf0I\xc1w\xecI\xc1w\xe8I\xc1w\xe4I\xc1w\xdcI\xc1w\xd4I\xc1w\xccI\xc1w\xc0I\xc1w\xb4I\xc1w\xacI\xc1w\xa0I\xc1w\x9cI\xc1w\x98I\xc1w\x94I\xc1w\x90I\xc1w\x8cI\xc1w\x88I\xc1w\x84I\xc1w\x80I\xc1w|I\xc1wxI\xc1wtI\xc1wpI\xc1whI\xc1w\I\xc1wTI\xc1wLI\xc1w\x8cI\xc1wDI\xc1w<I\xc1w4I\xc1w(I\xc1wI\xc1w\x14I\xc1w\x08I\xc1w\x04I\xc1w'

ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit
(Intel)] on win32


----------------------------------------------------------------------

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 20:34

Message:
Logged In: YES 
user_id=304464

On my linux system does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\x0e'

Python 2.3.3c1 (#2, Dec  6 2003, 16:44:56)
[GCC 3.3.3 20031203 (prerelease) (Debian)] on linux2

----------------------------------------------------------------------

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 20:32

Message:
Logged In: YES 
user_id=304464

Also, please have a look at:
https://sourceforge.net/tracker/index.php?func=detail&aid=898253&group_id=5470&atid=105470

at the same time.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-02-16 01:23

Message:
Logged In: YES 
user_id=31435

I assume this is specific to Python on Windows using 
Microsoft's C, since this workalike plain C program also dies 
with a memory error while in the bowels of MS's strftime():

#include <stdio.h>
#include <time.h>

void main() {
    struct tm t;
    char buf[256];
    size_t i;

    t.tm_year = 1900 - 1900;
    t.tm_mon = 1 - 1;
    t.tm_mday = 1;
    t.tm_hour = 13;
    t.tm_min = 0;
    t.tm_sec = 0;
    t.tm_wday = -3;
    t.tm_yday = 0;
    t.tm_isdst = -1;

    printf("calling strftime\n");
    i = strftime(buf, sizeof(buf), "%a", &t);
    printf("i: %d\n", i);
}

The problem is the negative value for tm_wday.  MS strftime 
isn't defensive, and uses the negative tm_wday to index into 
nonsense memory.  Ironically, if C had defined the % operator 
in the sane way (meaning Python's way <wink>), a negative 
tm_wday wouldn't have survived for the C library function to 
see.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-15 23:41

Message:
Logged In: YES 
user_id=80475

It is expected.  Well, now that I've confirmed it on Py2.3.3
and Py2.4, yes ;-) 

Is it desirable?  Heck no.

Brett, can you take a look at this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897625&group_id=5470

From noreply at sourceforge.net  Sat Feb 28 22:14:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Feb 28 22:14:28 2004
Subject: [ python-Feature Requests-906746 ] int object need more informative
	error message
Message-ID: <E1AxHPN-0004R3-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #906746, was opened at 2004-02-29 12:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=906746&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
Assigned to: Nobody/Anonymous (nobody)
Summary: int object need more informative error message

Initial Comment:
When int objects encounter a NotImplementedError, 
they don&#039;t say much about what the problem is and are 
too unfriendly.

Error messages can be more verbose.

>>> reduce(int.__add__, (1, 2L))
NotImplemented

>>> reduce(int.__add__, (1L, 2))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: descriptor &#039;__add__&#039; requires a &#039;int&#039; object but 
received a &#039;long&#039;


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=906746&group_id=5470