From noreply@sourceforge.net  Tue May  1 01:14:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Apr 2001 17:14:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-420304 ] getattr function w/ default
Message-ID: <E14uNoD-0001UX-00@usw-sf-web2.sourceforge.net>

Bugs item #420304, was updated on 2001-04-30 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: getattr function w/ default

Initial Comment:
In Python 2.1, when calling the builtin getattr 
function and supplying the (optional) default 
argument, this default is returned on any exception 
raised during PyObject_GetAttr, even if the exception 
is not an AttributeError.  I did not expect this 
behavior after reading the getattr documentation.  Is 
this the  intended behavior?  (If so, I think the 
documentation should be made clearer on this point.)

Example (providing a non-string as the attribute name):

>>> class Test:
... 	pass
... 
>>> t = Test()
>>> getattr(t, 1, "hello")
'hello'
>>> 


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

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


From noreply@sourceforge.net  Tue May  1 03:18:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Apr 2001 19:18:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-420343 ] SystemError from tuple() builtin
Message-ID: <E14uPjn-0000el-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: SystemError from tuple() builtin

Initial Comment:
The following produces a SystemError under Python 2.1:

>>> class Test:
... 	def __init__(self):
... 		self.list = [1]
... 	def __len__(self):
... 		return 0
... 	def __getitem__(self, index):
... 		return self.list[index]
... 
>>> t = Test()
>>> tuple(t)
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
SystemError: C:\USERS\greg\PROG\CPP\PYTHON\Python-2.1
\Objects\tupleobject.c:506: bad argument to internal 
function

The problem is the call made by PySequence_Tuple to 
_PyTuple_Resize.  The above code results in an attempt 
to resize the empty tuple, the ref count of which is 
greater than 1.




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

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


From noreply@sourceforge.net  Tue May  1 03:41:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 30 Apr 2001 19:41:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-420343 ] SystemError from tuple() builtin
Message-ID: <E14uQ6c-00011c-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: SystemError from tuple() builtin

Initial Comment:
The following produces a SystemError under Python 2.1:

>>> class Test:
... 	def __init__(self):
... 		self.list = [1]
... 	def __len__(self):
... 		return 0
... 	def __getitem__(self, index):
... 		return self.list[index]
... 
>>> t = Test()
>>> tuple(t)
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
SystemError: C:\USERS\greg\PROG\CPP\PYTHON\Python-2.1
\Objects\tupleobject.c:506: bad argument to internal 
function

The problem is the call made by PySequence_Tuple to 
_PyTuple_Resize.  The above code results in an attempt 
to resize the empty tuple, the ref count of which is 
greater than 1.




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

>Comment By: Greg Chapman (glchapman)
Date: 2001-04-30 19:41

Message:
Logged In: YES 
user_id=86307

Apropos this report and the recent python-dev 
thread "Iterators, map, xreadlines and docs":

>>> f = open(r"c:\autoexec.bat")
>>> l = list(f.xreadlines())
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: len() of unsized object

Admittedly, using xreadlines like this is silly, but it 
probably ought to work.  Both PySequence_Tuple and 
PySequence_List require len() (PySequence_Size) to succeed, 
even though they then pretty much ignore the returned 
length.  Perhaps they should be changed to be consistent 
with the changes in map.


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

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


From noreply@sourceforge.net  Tue May  1 09:33:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 01:33:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-420399 ] wrong HTML ("trademark" symbols?)
Message-ID: <E14uVbS-0004tZ-00@usw-sf-web3.sourceforge.net>

Bugs item #420399, was updated on 2001-05-01 01:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420399&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: wrong HTML ("trademark" symbols?)

Initial Comment:
In the files:
http://python.sourceforge.net/maint-docs/lib/allos.html
http://python.sourceforge.net/maint-docs/lib/unix.html
http://python.sourceforge.net/maint-docs/lib/misc.html
http://python.sourceforge.net/maint-
docs/lib/netdata.html

there are wrong HTML codes, right after the 
words "ASCII", "POSIX" and/or "Unix".
Maybe they correspond to trademark symbols?

I am browsing those files either with MSIE 5.5 or 
Netscape 6.0 on a Win2K machine.

[I seem to remember that this was reported before, but 
I couldn't find on sourceforge. Was it by mail?]

-Hernán


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

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


From noreply@sourceforge.net  Tue May  1 11:08:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 03:08:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Unicode Build Prob.
Message-ID: <E14uX4u-0005wo-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Schinckel (schinckel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python for BeOS/PPC Unicode Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

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

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


From noreply@sourceforge.net  Tue May  1 11:19:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 03:19:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-215844 ] OverflowError: integer multiplication
Message-ID: <E14uXG1-00064m-00@usw-sf-web3.sourceforge.net>

Bugs item #215844, was updated on 2000-10-02 06:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215844&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: OverflowError: integer multiplication

Initial Comment:

Python2.0b2 compiled from source on a full RH7.0 install:


Python 2.0b2 (#2, Sep 27 2000, 11:40:58) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 5 * 5
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer multiplication
>>>

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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-01 03:19

Message:
Logged In: YES 
user_id=193059

Hmm - I get a similar error under BeOS/PPC 5 using 2.1 (final)

Note that this occurs when setup.py is run on a 'make', I took it to 
be a build bug (unrelated to the other one I just submitted), but 
then realised it had built the interpreter and the exec, but was 
dying when trying to install...

The only multiplication that works with integers is 0*0.  If either 
is non-zero, it overflows.

The overflow seems to be in clause 3 of int_mul (the sixth occurance 
of 'goto bad;', but then even numbers multiplied by other numbers 
cause the fourth occurance of 'goto bad;' to be invoked if this goto 
is ignored.  I stopped commenting out goto's then, just in case I 
did something real bad - better left to the experts, hey guys...

As for make test - It wont get far enough to run tests:

Here is some transcript...

/boot/home/python/Python-2.1> make test
PYTHONPATH= ./python.xSYM ./setup.py build
Traceback (most recent call last):
  File "./setup.py", line 10, in ?
    from distutils import sysconfig
  File "/boot/home/python/Python-2.1/Lib/distutils/sysconfig.py", 
line 181, in ?
    _variable_rx = re.compile("([a-zA-Z][a-zA-Z0-9_]+)\s*=\s*(.*)")
  File "/boot/home/python/Python-2.1/Lib/sre.py", line 90, in 
compile
    return _compile(pattern, flags)
  File "/boot/home/python/Python-2.1/Lib/sre.py", line 134, in 
_compile
    p = sre_compile.compile(pattern, flags)
  File "/boot/home/python/Python-2.1/Lib/sre_compile.py", line 368, 
in compile
    code = _code(p, flags)
  File "/boot/home/python/Python-2.1/Lib/sre_compile.py", line 352, 
in _code
    _compile(code, p.data, flags)
  File "/boot/home/python/Python-2.1/Lib/sre_compile.py", line 78, 
in _compile
    emit((av[0]-1)*2)
OverflowError: integer multiplication
make: *** [sharedmods] Error 1

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

Comment By: Jeremy Hylton (jhylton)
Date: 2000-10-05 07:53

Message:
same fix as other integer multiplication bug; report error at compile-time if compiler has bogus definition of LONG_BITS


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

Comment By: Tim Peters (tim_one)
Date: 2000-10-04 18:59

Message:
Note that I just checked in changes to intobject.c and pyport.h to do a compile-time #error if LONG_BIT appears to be insanely defined by the platform.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2000-10-03 11:17

Message:
This bug has also been reported on a system using gcc2.95, so I'm going try with that version of GCC.  It doesn't sound like this is a 64-bit platform; does RH7 run on a 64-bit platform?  It does appear that the problem is caused by LONG_BIT being too big resulting in a bogus shift.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-10-03 10:30

Message:
I don't see any reference to GCC 2.96 on the GCC website (http://gcc.gnu.org/).  PythonLabs should be a RH7.0 box to perform testing.

This may be a duplicate of #1159191.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-03 10:21

Message:
Could it be a 64-bit bug? Otherwise I suspect a GCC bug, or a 64-bit GCC bug. Note that GCC 2.96 is bleeding edge!

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

Comment By: Jeremy Hylton (jhylton)
Date: 2000-10-03 08:27

Message:
Strange! Another bug about integer multiplication overflow.  The other one is on a Debian install.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-02 06:39

Message:
Something very basic is wrong. What output does the test suite give? ("make test"). Please see the README for digging into this.

Note that you submitted your bug report anonymously. We can't help you very effectively unless we can exchange email with you!

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

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


From noreply@sourceforge.net  Tue May  1 17:02:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 09:02:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-420476 ] Python 2.1 'make test' failures: AIX 4.2
Message-ID: <E14ucbT-0001zo-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 'make test' failures: AIX 4.2

Initial Comment:
Successfully built and installed Python 2.1 on AIX 
4.2.  However, 3 regression tests failed.  The output 
from 'make test' (edited for brevity) is shown below:

make test
...successful tests deleted...
test___all__
test test___all__ failed -- tty has no __all__ 
attribute
...successful tests deleted...
test_coercion
The actual stdout doesn't match the expected stdout.
This much did match (between asterisk lines):
*******************************************************
***************
test_coercion
2 + 2 = 4
2 += 2 => 4
2 - 2 = 0
2 -= 2 => 0
2 * 2 = 4
2 *= 2 => 4
2 / 2 = 1
2 /= 2 => 1
2 ** 2 = 4
2 **= 2 => 4
2 % 2 = 0
2 %= 2 => 0
2 + 4.0 = 6.0
2 += 4.0 => 6.0
2 - 4.0 = -2.0
2 -= 4.0 => -2.0
2 * 4.0 = 8.0
2 *= 4.0 => 8.0
2 / 4.0 = 0.5
2 /= 4.0 => 0.5
2 ** 4.0 = 16.0
2 **= 4.0 => 16.0
2 % 4.0 = 2.0
2 %= 4.0 => 2.0
2 + 2 = 4
2 += 2 => 4
2 - 2 = 0
2 -= 2 => 0
2 * 2 = 4
2 *= 2 => 4
2 / 2 = 1
2 /= 2 => 1
2 ** 2 = 4
2 **= 2 => 4
2 % 2 = 0
2 %= 2 => 0
2 + (2+0j) = (4+0j)
2 += (2+0j) => (4+0j)
2 - (2+0j) = 0j
2 -= (2+0j) => 0j
2 * (2+0j) = (4+0j)
2 *= (2+0j) => (4+0j)
2 / (2+0j) =
*******************************************************
***************
Then ...
We expected (repr): '(1+0j)'
But instead we got: '(1-0j)'
test test_coercion failed -- Writing: '(1-0j)', 
expected: '(1+0j)'
...successful tests deleted...
test_pty
test test_pty failed -- Tail of expected stdout 
unseen: 'y pet fish, Eric.\n'
...successful tests deleted...
test_zlib
test test_zlib skipped --  No module named zlib
112 tests OK.
3 tests failed: test___all__ test_coercion test_pty
22 tests skipped: test_al test_bsddb test_cd test_cl 
test_dl test_gdbm test_gl test_gzip test_imgfile 
test_largefile test_linuxaudio
dev test_minidom test_nis test_openpty test_pyexpat 
test_sax test_sunaudiodev test_sundry test_winreg 
test_winsound test_zipfile test_zlib
make: 1254-004 The error code from the last command is 
1.


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

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


From noreply@sourceforge.net  Tue May  1 18:06:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 10:06:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-420490 ] lookdict_string does not use interning
Message-ID: <E14udbc-000691-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: lookdict_string does not use interning

Initial Comment:
In Python 2.1, when a dictionary uses lookdict_string 
to retrieve items, the function used to compare 
strings is PyString_Type.tp_compare, i.e. 
string_compare.  string_compare does not check if its 
parameters are actually the same PStringObject *, so 
an actual string comparison is made even if the 
dictionary's keys have been interned.  Python 1.52 
used PyObject_Compare to compare all keys, and this 
function did check to see if its parameters were the 
same PyObject *.

I wonder if this might be one source of the slow-down 
in Python 2.1?


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

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


From noreply@sourceforge.net  Tue May  1 18:17:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 10:17:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-420490 ] lookdict_string does not use interning
Message-ID: <E14udm5-0005YN-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: lookdict_string does not use interning

Initial Comment:
In Python 2.1, when a dictionary uses lookdict_string 
to retrieve items, the function used to compare 
strings is PyString_Type.tp_compare, i.e. 
string_compare.  string_compare does not check if its 
parameters are actually the same PStringObject *, so 
an actual string comparison is made even if the 
dictionary's keys have been interned.  Python 1.52 
used PyObject_Compare to compare all keys, and this 
function did check to see if its parameters were the 
same PyObject *.

I wonder if this might be one source of the slow-down 
in Python 2.1?


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

>Comment By: Greg Chapman (glchapman)
Date: 2001-05-01 10:17

Message:
Logged In: YES 
user_id=86307

Actually, to be more specific, only the first comparison in 
lookdict_string forgets to see if the string pointers are 
the same.  I assume the proper fix would be to change this 
first comparison to be:

 	if (ep->me_key == dummy)
 		freeslot = ep;
 	else {
-		if (ep->me_hash == hash
-		    && compare(ep->me_key, key) == 0) {
+		if (ep->me_key == key
+                    || (ep->me_hash == hash
+		    && compare(ep->me_key, key) == 0)) {
 			return ep;
 		}
 		freeslot = NULL;
 	}


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

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


From noreply@sourceforge.net  Tue May  1 18:20:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 10:20:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-420490 ] lookdict_string does not use interning
Message-ID: <E14udpE-0002zZ-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: lookdict_string does not use interning

Initial Comment:
In Python 2.1, when a dictionary uses lookdict_string 
to retrieve items, the function used to compare 
strings is PyString_Type.tp_compare, i.e. 
string_compare.  string_compare does not check if its 
parameters are actually the same PStringObject *, so 
an actual string comparison is made even if the 
dictionary's keys have been interned.  Python 1.52 
used PyObject_Compare to compare all keys, and this 
function did check to see if its parameters were the 
same PyObject *.

I wonder if this might be one source of the slow-down 
in Python 2.1?


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

>Comment By: Greg Chapman (glchapman)
Date: 2001-05-01 10:20

Message:
Logged In: YES 
user_id=86307

Actually, I apologize for wasting everyone's time.  This 
report is totally false; I missed this line:

	if (ep->me_key == NULL || ep->me_key == key)
		return ep;

Please ignore this.  I'm going to go get some sleep.



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

Comment By: Greg Chapman (glchapman)
Date: 2001-05-01 10:17

Message:
Logged In: YES 
user_id=86307

Actually, to be more specific, only the first comparison in 
lookdict_string forgets to see if the string pointers are 
the same.  I assume the proper fix would be to change this 
first comparison to be:

 	if (ep->me_key == dummy)
 		freeslot = ep;
 	else {
-		if (ep->me_hash == hash
-		    && compare(ep->me_key, key) == 0) {
+		if (ep->me_key == key
+                    || (ep->me_hash == hash
+		    && compare(ep->me_key, key) == 0)) {
 			return ep;
 		}
 		freeslot = NULL;
 	}


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

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


From noreply@sourceforge.net  Tue May  1 18:21:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 10:21:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-420498 ] no docs for pydoc
Message-ID: <E14udq4-000304-00@usw-sf-web3.sourceforge.net>

Bugs item #420498, was updated on 2001-05-01 10:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420498&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Goodger (goodger)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: no docs for pydoc

Initial Comment:
The pydoc.py module lacks an entry in the Python 
Library Reference. There's no mention of pydoc 
anywhere else in the standard documentation (Doc/ dir) 
either.

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

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


From noreply@sourceforge.net  Tue May  1 18:40:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 10:40:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-420502 ] seek/tell beyond eof without exceptions
Message-ID: <E14ue8G-0003G7-00@usw-sf-web3.sourceforge.net>

Bugs item #420502, was updated on 2001-05-01 10:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420502&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grzegorz Makarewicz (mpmak)
Assigned to: Nobody/Anonymous (nobody)
Summary: seek/tell beyond eof without exceptions

Initial Comment:

Methods from FileObject like seek/tell doesn`t check 
for errno value. The result is that python exceptions 
aren`t throwned.

Small example:

import sys
SEEK_END = 2

def main():
	fp=open(sys.argv[0],'rb')
	fp.seek(0,SEEK_END)
	off = fp.tell()
	fp.seek(off,SEEK_END)
	x = fp.tell()
	print 'tell?',x

main()


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

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


From noreply@sourceforge.net  Tue May  1 22:20:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 14:20:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E14uhZk-00024G-00@usw-sf-web1.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



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

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:20

Message:
Logged In: YES 
user_id=22448

This is related to bug #419873.
The problem is not specifically in the ThreadingMixin
specifically, but where BaseServer calls close_request()
after calling process_request().  In the threading mixin,
process_request() spins the thread and returns, causing the
request socket to be invalidated while the thread is still
running.  The fix given above will keep the socket valid
while the thread is running, but may cause the socket to not
close properly (my threads generally close the socket when
they are done anyway.)

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

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

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


From noreply@sourceforge.net  Tue May  1 22:25:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 14:25:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-419873 ] ThreadingTCPServer invalidating sockets
Message-ID: <E14uhe4-0002A7-00@usw-sf-web1.sourceforge.net>

Bugs item #419873, was updated on 2001-04-28 16:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419873&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ThreadingTCPServer invalidating sockets

Initial Comment:
running this:
import SocketServer

class TestServer(SocketServer.ThreadingTCPServer):
    def __init__(self, server_address,
RequestHandlerClass):
        SocketServer.ThreadingTCPServer.__init__(self,
server_address, RequestHandlerClass)
        self.quit = 0

    def process_request(self, request, client_address):
        print 'socket in process_request = %s' % request
        print 'id(socket) in process_request = %d' %
id(request)
       
SocketServer.ThreadingTCPServer.process_request(self,
request, client_address)

    def finish_request(self, request, client_address):
        print 'socket in finish_request = %s' % request
        print 'id(socket) in finish_request = %d' %
id(request)
        self.RequestHandlerClass(request,
client_address, self)
    
    def get_request(self):
        conn, addr = self.socket.accept()
        print 'socket in get_request = %s' % conn
        print 'id(socket) in get_request = %d' % id(conn)
        return conn,addr

if __name__ == '__main__':
    s = TestServer(('',9950),
SocketServer.BaseRequestHandler)
    s.handle_request()
    s.server_close()

results in the following output (when connected to
remotely):

socket in get_request = <socket object, fd=4, family=2,
type=1, protocol=0>
id(socket) in get_request = 135335216
socket in process_request = <socket object, fd=4,
family=2, type=1, protocol=0>
id(socket) in process_request = 135335216
socket in finish_request = <socket object, fd=-1,
family=2, type=1, protocol=0>
id(socket) in finish_request = 135335216

between in the thread-creation in process_request, the
socket's fd changes to -1.

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

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:25

Message:
Logged In: YES 
user_id=22448

See comments for bug #417845.
BaseServer.handle_request() potentially (more like
consistently) calls close_request() before the thread spun
in process_request() is able to complete.  A work around is
shown in bug #417845 (overload close_request() to do nothing
instead of closing the socket.)

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

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


From noreply@sourceforge.net  Wed May  2 02:07:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 01 May 2001 18:07:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-420601 ] --with-next-framework very broken on OSX
Message-ID: <E14ul7E-0005xf-00@usw-sf-web1.sourceforge.net>

Bugs item #420601, was updated on 2001-05-01 18:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420601&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Nobody/Anonymous (nobody)
Summary: --with-next-framework very broken on OSX

Initial Comment:
This bug report is not going to have a lot of useful 
data;  mostly just to get it into the system to see if 
others may care (or already be working on it).

In any case, --with-next-frameworks is quite broken 
under OSX.   It may not even really be pertinent any 
longer, but I have yet to verify that [investigation 
commences soon].

- executes ranlib against the dylib which breaks on 
OSX

- doesn't actually build a framework at all, but 
installs a dynamically loadable library (which may 
actually be more appropriate, all things 
considered)

- fails to install the dylib or any of the other .so 
modules in the actual platform specific directory 
where one might expect.  Instead, they end up in 
the generic dylib directory, but the PYTHONPATH 
does not search that directory.

- python executable will not launch because the 
dylib cannot be found.   However, given that the 
python executable does not have any kind of path 
information for the dylib, I'm not sure it would find it 
even if the dylib were installed in a "more correct" 
place.

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

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


From noreply@sourceforge.net  Wed May  2 09:41:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 01:41:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E14usC3-0006Ol-00@usw-sf-web3.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-02 01:41

Message:
Logged In: YES 
user_id=80200

hi there mr jrielh,

thank you very much for the details.  what i am having a
little difficulty with is, what's the difference between
this and python 2.0 SocketServer.py?

more specifically, i'm looking at python 2.0 SocketServer.py
and, whilst i'm not a Threads expert, i see a t.start() but
no t.join().  i've been looking at the Queue example code in
the test method of threads.py, and start() is called on
every thread, followed by join() on every thread.  join
waits for the thread to finish, yes?

so... if that's the case, then python 2.0 SocketServer.py
should suffer from
exactly the same behaviour, yes?  unless python behaves
ever-so-slightly differently (timing issues?) when you have
an extra base class like this,
with the consequence that close_request() is more likely to
be called
before ThreadingMixIn.process_request().

?

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

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:20

Message:
Logged In: YES 
user_id=22448

This is related to bug #419873.
The problem is not specifically in the ThreadingMixin
specifically, but where BaseServer calls close_request()
after calling process_request().  In the threading mixin,
process_request() spins the thread and returns, causing the
request socket to be invalidated while the thread is still
running.  The fix given above will keep the socket valid
while the thread is running, but may cause the socket to not
close properly (my threads generally close the socket when
they are done anyway.)

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

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

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


From noreply@sourceforge.net  Wed May  2 13:50:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 05:50:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Unicode Build Prob.
Message-ID: <E14uw5D-0000QY-00@usw-sf-web1.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Schinckel (schinckel)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: Python for BeOS/PPC Unicode Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

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

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


From noreply@sourceforge.net  Wed May  2 14:18:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 06:18:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-417030 ] print '%*s' fails for unicode string
Message-ID: <E14uwW0-0001OM-00@usw-sf-web3.sourceforge.net>

Bugs item #417030, was updated on 2001-04-18 05:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417030&group_id=5470

>Category: Unicode
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Barry Alan Scott (barry-scott)
Assigned to: M.-A. Lemburg (lemburg)
Summary: print '%*s' fails for unicode string

Initial Comment:
Python 2.0 (#8, Dec 13 2000, 09:47:07) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> print '%*s' % (7,u'fred')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: * wants int
>>>


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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 06:18

Message:
Logged In: YES 
user_id=38388

I'll check in a patch for this into CVS later today.

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

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


From noreply@sourceforge.net  Wed May  2 15:09:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 07:09:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-420720 ] Starting many threads causes core dump
Message-ID: <E14uxJc-00028D-00@usw-sf-web3.sourceforge.net>

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

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Starting many threads causes core dump

Initial Comment:
If I start more than 1020 threads simultaneously, using
the threading module, Python 2.1 causes segmentation
faults, or will not exit, under Linux. I have not
tested this on Windows.

I don't know whether the problems are caused by the
threads themselves, or the threading.Event for which
they are waiting.

I have attached a program threadKill3.py which
demonstrates this (including sample runs and output).


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

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


From noreply@sourceforge.net  Wed May  2 15:42:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 07:42:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-420724 ] urllib2 and non existing local files
Message-ID: <E14uxpy-0002aR-00@usw-sf-web3.sourceforge.net>

Bugs item #420724, was updated on 2001-05-02 07:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420724&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 and non existing local files

Initial Comment:
When trying to open local files
with urllib2 in Python 2.1 urllib2 raises
an AssertionError instead of an IOError:

>>> import urllib2
>>> f = urllib2.urlopen("I don't exist")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/urllib2.py", line 
135, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.1/urllib2.py", line 
316, in open
    type_ = req.get_type()
  File "/usr/local/lib/python2.1/urllib2.py", line 
220, in get_type
    assert self.type is not None, self.__original
AssertionError: I don't exist


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

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


From noreply@sourceforge.net  Wed May  2 15:46:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 07:46:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-420725 ] urllib: MIME header for local files
Message-ID: <E14uxtn-0005vC-00@usw-sf-web2.sourceforge.net>

Bugs item #420725, was updated on 2001-05-02 07:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420725&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib: MIME header for local files

Initial Comment:
For local files urllib.py doesn't return the MIME 
headers that the documentation says it does:

http://www.python.org/doc/current/lib/module-
urllib.html#l2h-2187 states that "When the method is 
local-file, returned headers will include a Date 
representing the file's last-modified time, a Content-
Length giving file size, and a Content-Type containing 
a guess at the file's type"

But in Python 2.1 the only header that gets returned
is the Content-Type:

>>> import urllib
>>> f = urllib.urlopen("gurk.txt")      
>>> f.info().headers  
['Content-Type: text/plain\n']


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

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


From noreply@sourceforge.net  Wed May  2 17:22:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 09:22:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-420725 ] urllib: MIME header for local files
Message-ID: <E14uzOZ-0003xa-00@usw-sf-web3.sourceforge.net>

Bugs item #420725, was updated on 2001-05-02 07:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420725&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib: MIME header for local files

Initial Comment:
For local files urllib.py doesn't return the MIME 
headers that the documentation says it does:

http://www.python.org/doc/current/lib/module-
urllib.html#l2h-2187 states that "When the method is 
local-file, returned headers will include a Date 
representing the file's last-modified time, a Content-
Length giving file size, and a Content-Type containing 
a guess at the file's type"

But in Python 2.1 the only header that gets returned
is the Content-Type:

>>> import urllib
>>> f = urllib.urlopen("gurk.txt")      
>>> f.info().headers  
['Content-Type: text/plain\n']


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

>Comment By: Walter Dörwald (doerwalter)
Date: 2001-05-02 09:22

Message:
Logged In: YES 
user_id=89016

A patch (#420753) has been upload to SF.

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

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


From noreply@sourceforge.net  Wed May  2 18:11:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 10:11:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-420771 ] 'rw' option to open: is it a bug?
Message-ID: <E14v0AH-0004dI-00@usw-sf-web3.sourceforge.net>

Bugs item #420771, was updated on 2001-05-02 10:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420771&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'rw' option to open: is it a bug?

Initial Comment:
if you open a file with 'rw'

f = open('foo.bar','rw')
ie you will be able to read, but not write

Python 2.1 (#3, Apr 19 2001, 11:45:56) [C] on sunos5
Type "copyright", "credits" or "license" for more
information.
>>> f = open("foo.bar",'rw')
>>> f.read()
'HelloWorld\n'
>>> f.write("NotWhatIExpect")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file number
>>> 

However the rw does not seem to be a valid option, yet
no error is produced upon opening the file, rather
when the operation is attempted.

It seems that what is needed if you want
'rw' is 'r+'.

>>> f = open("foo.bar",'r+')
>>> f.read() 
'HelloWorld\n'
>>> f.write("ThisIsWhatIExpect")
>>> f.close()

Could therefore 'rw' signal an error? Or do the
same as 'r+'?

  

 

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

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


From noreply@sourceforge.net  Wed May  2 18:57:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 10:57:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-420771 ] 'rw' option to open: is it a bug?
Message-ID: <E14v0sQ-0000CN-00@usw-sf-web2.sourceforge.net>

Bugs item #420771, was updated on 2001-05-02 10:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420771&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'rw' option to open: is it a bug?

Initial Comment:
if you open a file with 'rw'

f = open('foo.bar','rw')
ie you will be able to read, but not write

Python 2.1 (#3, Apr 19 2001, 11:45:56) [C] on sunos5
Type "copyright", "credits" or "license" for more
information.
>>> f = open("foo.bar",'rw')
>>> f.read()
'HelloWorld\n'
>>> f.write("NotWhatIExpect")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file number
>>> 

However the rw does not seem to be a valid option, yet
no error is produced upon opening the file, rather
when the operation is attempted.

It seems that what is needed if you want
'rw' is 'r+'.

>>> f = open("foo.bar",'r+')
>>> f.read() 
'HelloWorld\n'
>>> f.write("ThisIsWhatIExpect")
>>> f.close()

Could therefore 'rw' signal an error? Or do the
same as 'r+'?

  

 

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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-02 10:57

Message:
Logged In: YES 
user_id=31435

Python doesn't look at the mode argument:  it passes it on 
as-is to the platform C fopen() function.  This allows 
people to use whatever non-standard modes their platform 
supports.  An error is reported if and only if the platform 
fopen() sets errno across the call.

Mode "rw" isn't defined by C ("r+" and "w+" are), so 
whether a platform accepts it is up to the platform; and, 
if it does accept it, what it means is also up to the 
platform.  So that "rw" was accepted when you tried it 
means that sunos5's fopen() accepts an "rw" mode.  You'll 
have to consult Sun's docs for whether it's working as they 
intended it to work.

Could be useful if Python warned about non-standard modes.

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

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


From noreply@sourceforge.net  Wed May  2 20:46:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 12:46:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-420828 ] Marshal fails on load of big tuple.
Message-ID: <E14v2aC-0001hA-00@usw-sf-web2.sourceforge.net>

Bugs item #420828, was updated on 2001-05-02 12:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420828&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Marshal fails on load of big tuple.

Initial Comment:
##marshalBug.py
##   This is code that demonstrates the bug
##   Bug only occurs with marshal load and save, not loads and saves,
##   Bug (to my knowledge) occurs only in Windows distribution (Tested on linux)
##
##   On Idle command line bug can be duplicated with following:
##
#>>> f.close()
#>>> f = open("C:\temp\deleteme","w")
#>>> marshal.dump((12999999999999999999999999999999999999999977777777777777777777
#77777777777777777777777777777777777777777777777777777777777777777777777777777777
#77777777777777777777777777777777777777777777777777777777777777777777777777777777
#77777777777777777775555555555555555555555555555555555333333333333333333333333333
#333333333333333333333335555555555555555L, 12222222222222222222222222222222222222
#22222224444444444444444444444444444444444444888888888888888888888888888888888888
#88889999999999999999999999999999999999999999999999999999999999900000000000000000
#000000000088888888888888888888888888888888888888L),f)
#>>> f.close()
#>>> f = open("C:\temp\deleteme","r")
#>> marshal.load(f)
#(1299999999999999999999999999999999999999997777777777777777777777777777777777777
#77777777777777777777777777777777777777777777777777777777777777777777777777777777
#77777777777777777777777777777777777777777777777777777777777777777777777777777777
#77555555555555555555555555555555555533333333333333333333333333333333333333333333
#3333335555555555555555L, 4474897019813323481254923506055493475928166048940730464
#14109805177692967484150062868771650107391063365906217439770564386204965711909753
#84487052159509613681529022093399596597392467587045506856658934454268182437193534
#6828317880575604459910185571552824L)
#>>> f.close()
import marshal

## Test1
f = open("C:\temp\deleteme","w")
a = 
1299999999999999999999999999999999999999997777777777777777777777777777777777777777
7
7777777777777777777777777777777777777777777777777777777777777777777777777777777777
7
7777777777777777777777777777777777777777777777777777777777777777777777777775555555
5
5555555555555555555555555533333333333333333333333333333333333333333333333333555555
5
555555555L
b = 
1222222222222222222222222222222222222222222224444444444444444444444444444444444444
8
8888888888888888888888888888888888888889999999999999999999999999999999999999999999
9
99999999999999900000000000000000000000000088888888888888888888888888888888888888L
marshal.dump((a,b,),f)
f.close()
f = open("C:\temp\deleteme","r")
x,y = marshal.load(f)
f.close()
if a == x:
   print "First element of Tuple OK"
else:
   print "First element of Tuple Fails with:"
   print a,"!=",x
if b == y:
   print "Second of Tuple OK"
else:
   print "Second element of Tuple Fails with:"
   print b,"!=",y

## Test2:  Works with smaller integers.
##f = open("C:\temp\deleteme","w")
##a = 1299999999999999999999L
##b = 1222222222222222222222L
##marshal.dump((a,b,),f)
##f.close()
##f = open("C:\temp\deleteme","r")
##x,y = marshal.load(f)
##f.close()
##if a == x:
##   print "First element of Tuple OK"
##else:
##   print a,"!=",x
##if b == y:
##   print "Second element of Tuple OK"
##else:
##   print b,"!=",y




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

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


From noreply@sourceforge.net  Wed May  2 21:26:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 13:26:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-420498 ] no docs for pydoc
Message-ID: <E14v3CI-0002FG-00@usw-sf-web2.sourceforge.net>

Bugs item #420498, was updated on 2001-05-01 10:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420498&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: David Goodger (goodger)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: no docs for pydoc

Initial Comment:
The pydoc.py module lacks an entry in the Python 
Library Reference. There's no mention of pydoc 
anywhere else in the standard documentation (Doc/ dir) 
either.

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

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

Message:
Logged In: YES 
user_id=3066

Raised the priority of this.

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

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


From noreply@sourceforge.net  Wed May  2 21:32:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 13:32:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-420851 ] Missing docs for iteration support.
Message-ID: <E14v3ID-0002Kk-00@usw-sf-web2.sourceforge.net>

Bugs item #420851, was updated on 2001-05-02 13:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420851&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Missing docs for iteration support.

Initial Comment:
Documentation is needed for the iteration support.  At this time, the following things are missing docs:

- iter() function
- {}.iteritems(), .iterkeys(), .itervalues()
- tp_iter/tp_iternext
- __iter__() (ref. manual -- "Object Customization")

If you can think of other aspects of this that I've missed, please note them as comments on this bug report so I can address these (or at least keep track of these) in a single place.


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

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


From noreply@sourceforge.net  Thu May  3 00:24:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 02 May 2001 16:24:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-420828 ] Marshal fails on load of big tuple.
Message-ID: <E14v5zD-0003r4-00@usw-sf-web1.sourceforge.net>

Bugs item #420828, was updated on 2001-05-02 12:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420828&group_id=5470

Category: Windows
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Marshal fails on load of big tuple.

Initial Comment:
##marshalBug.py
##   This is code that demonstrates the bug
##   Bug only occurs with marshal load and save, not loads and saves,
##   Bug (to my knowledge) occurs only in Windows distribution (Tested on linux)
##
##   On Idle command line bug can be duplicated with following:
##
#>>> f.close()
#>>> f = open("C:\temp\deleteme","w")
#>>> marshal.dump((12999999999999999999999999999999999999999977777777777777777777
#77777777777777777777777777777777777777777777777777777777777777777777777777777777
#77777777777777777777777777777777777777777777777777777777777777777777777777777777
#77777777777777777775555555555555555555555555555555555333333333333333333333333333
#333333333333333333333335555555555555555L, 12222222222222222222222222222222222222
#22222224444444444444444444444444444444444444888888888888888888888888888888888888
#88889999999999999999999999999999999999999999999999999999999999900000000000000000
#000000000088888888888888888888888888888888888888L),f)
#>>> f.close()
#>>> f = open("C:\temp\deleteme","r")
#>> marshal.load(f)
#(1299999999999999999999999999999999999999997777777777777777777777777777777777777
#77777777777777777777777777777777777777777777777777777777777777777777777777777777
#77777777777777777777777777777777777777777777777777777777777777777777777777777777
#77555555555555555555555555555555555533333333333333333333333333333333333333333333
#3333335555555555555555L, 4474897019813323481254923506055493475928166048940730464
#14109805177692967484150062868771650107391063365906217439770564386204965711909753
#84487052159509613681529022093399596597392467587045506856658934454268182437193534
#6828317880575604459910185571552824L)
#>>> f.close()
import marshal

## Test1
f = open("C:\temp\deleteme","w")
a = 
1299999999999999999999999999999999999999997777777777777777777777777777777777777777
7
7777777777777777777777777777777777777777777777777777777777777777777777777777777777
7
7777777777777777777777777777777777777777777777777777777777777777777777777775555555
5
5555555555555555555555555533333333333333333333333333333333333333333333333333555555
5
555555555L
b = 
1222222222222222222222222222222222222222222224444444444444444444444444444444444444
8
8888888888888888888888888888888888888889999999999999999999999999999999999999999999
9
99999999999999900000000000000000000000000088888888888888888888888888888888888888L
marshal.dump((a,b,),f)
f.close()
f = open("C:\temp\deleteme","r")
x,y = marshal.load(f)
f.close()
if a == x:
   print "First element of Tuple OK"
else:
   print "First element of Tuple Fails with:"
   print a,"!=",x
if b == y:
   print "Second of Tuple OK"
else:
   print "Second element of Tuple Fails with:"
   print b,"!=",y

## Test2:  Works with smaller integers.
##f = open("C:\temp\deleteme","w")
##a = 1299999999999999999999L
##b = 1222222222222222222222L
##marshal.dump((a,b,),f)
##f.close()
##f = open("C:\temp\deleteme","r")
##x,y = marshal.load(f)
##f.close()
##if a == x:
##   print "First element of Tuple OK"
##else:
##   print a,"!=",x
##if b == y:
##   print "Second element of Tuple OK"
##else:
##   print b,"!=",y




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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-02 16:24

Message:
Logged In: YES 
user_id=31435

Not a bug.  marshal is a binary format, and you're opening 
the file in text mode.  This makes a huge difference under 
Windows, but none under Linux.  Change the "w" and "r" in 
your open() statements to "wb" and "rb"; then the problem 
will go away.  Never open a binary file in text mode if you 
want your code to be portable.


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

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


From noreply@sourceforge.net  Fri May  4 00:26:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 May 2001 16:26:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E14vSU8-0006yw-00@usw-sf-web2.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



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

Comment By: Gregory P. Smith (greg)
Date: 2001-05-03 16:26

Message:
Logged In: YES 
user_id=413

Just a note of another casualty of this bug: I had to add
the mentioned dummy close_request method hack to our own
ThreadingMixIn class in mojo nation (in the sourceforge
mojonation project's evil module, see the
common/MojoNationHTTPServer.py file).  Without it, python
2.1 would always raise an exception in the request handler
as soon as it tried to call self.connection.makefile()
because self.connection had apparently already been closed! 
(its fd was always -1)


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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-02 01:41

Message:
Logged In: YES 
user_id=80200

hi there mr jrielh,

thank you very much for the details.  what i am having a
little difficulty with is, what's the difference between
this and python 2.0 SocketServer.py?

more specifically, i'm looking at python 2.0 SocketServer.py
and, whilst i'm not a Threads expert, i see a t.start() but
no t.join().  i've been looking at the Queue example code in
the test method of threads.py, and start() is called on
every thread, followed by join() on every thread.  join
waits for the thread to finish, yes?

so... if that's the case, then python 2.0 SocketServer.py
should suffer from
exactly the same behaviour, yes?  unless python behaves
ever-so-slightly differently (timing issues?) when you have
an extra base class like this,
with the consequence that close_request() is more likely to
be called
before ThreadingMixIn.process_request().

?

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

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:20

Message:
Logged In: YES 
user_id=22448

This is related to bug #419873.
The problem is not specifically in the ThreadingMixin
specifically, but where BaseServer calls close_request()
after calling process_request().  In the threading mixin,
process_request() spins the thread and returns, causing the
request socket to be invalidated while the thread is still
running.  The fix given above will keep the socket valid
while the thread is running, but may cause the socket to not
close properly (my threads generally close the socket when
they are done anyway.)

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

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

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


From noreply@sourceforge.net  Fri May  4 01:55:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 May 2001 17:55:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-420304 ] getattr function w/ default
Message-ID: <E14vTsC-0002qS-00@usw-sf-web1.sourceforge.net>

Bugs item #420304, was updated on 2001-04-30 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: getattr function w/ default

Initial Comment:
In Python 2.1, when calling the builtin getattr 
function and supplying the (optional) default 
argument, this default is returned on any exception 
raised during PyObject_GetAttr, even if the exception 
is not an AttributeError.  I did not expect this 
behavior after reading the getattr documentation.  Is 
this the  intended behavior?  (If so, I think the 
documentation should be made clearer on this point.)

Example (providing a non-string as the attribute name):

>>> class Test:
... 	pass
... 
>>> t = Test()
>>> getattr(t, 1, "hello")
'hello'
>>> 


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

Comment By: Chris Cogdon (chriscog)
Date: 2001-05-03 17:55

Message:
Logged In: YES 
user_id=67116

Looks like an attribute error to me. consider this:

>>> getattr (t,fred,"thingy")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: There is no variable named 'fred'

Ie, in your own example, it couldn't find an attribute '1' 
in the class, even if its an integer attribute (which is 
only obtainable using getattr/setattr). That's exactly what 
AttributeError is

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

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


From noreply@sourceforge.net  Fri May  4 02:00:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 May 2001 18:00:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-417930 ] += not assigning to same var it reads
Message-ID: <E14vTx9-00085Y-00@usw-sf-web2.sourceforge.net>

Bugs item #417930, was updated on 2001-04-21 16:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417930&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Edward Loper (edloper)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: += not assigning to same var it reads

Initial Comment:
My understanding of the augmented assignment 
statements is that they should always assign to the 
variable that they read from.  However, consider the 
following Python session:
  >>> class A: x = 1  
  ...  
  >>> a=A()
  >>> a.x += 1
  >>> a.x, A.x
  (2, 1)

Here, the expression "a.x += 1" read from a class 
variable, and wrote to an instance variable.  A 
similar effect can occur within a member function:
  >>> class A:
  ...     x = 1
  ...     def f(s): s.x += 1
  ... 
  >>> a = A()
  >>> a.f()
  >>> a.x, A.x
  (2, 1)

I have elicited this behavior in Python 2.0 and 2.1 
under Linux (Redhat 6.0), and Python 2.0 on sunos5.


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

Comment By: Chris Cogdon (chriscog)
Date: 2001-05-03 18:00

Message:
Logged In: YES 
user_id=67116

IMHO, this is not a bug. Assignments are always made to the 
class instance, not the class type. X+=1 should be 
equivalent to going X=X+1, and is just so in the above 
cases.

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

Comment By: Tim Peters (tim_one)
Date: 2001-04-21 19:46

Message:
Logged In: YES 
user_id=31435

Sorry, but your understanding is flawed.  Changed the 
category to Documentation and assigned to Fred, because I 
agree the Ref Man isn't clear enough here:  "The target is 
evaluated only once" is certainly how Guido *thinks* of it, 
but it really needs a by-cases explanation:

For an attributeref target, the primary expression in the 
reference is evaluated only once, but a getattr is done on 
the RHS and a setattr on the LHS.  That is,

    e1.attr op= e2

acts like

    temp1 = e1
    temp2 = e2
    temp1.attr = temp1.attr op temp2

Etc.  It's going to take some real work to write this up so 
they're comprehensible!  I recommend skipping most words 
and presenting "workalike" pseudo-code sequences instead.  
That will take some sessions with the disassembler to be 
sure the pseudo-code is 100% accurate.

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

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


From noreply@sourceforge.net  Fri May  4 02:18:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 May 2001 18:18:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-421212 ] PythonPath registry value ignored in Py2
Message-ID: <E14vUF5-0004kE-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: PythonPath registry value ignored in Py2

Initial Comment:
The difference I see between this and 229584
is that there are subkeys under ..\2.1\PythonPath
as I installed win32extensions (bld 139).

I still cannot pick up these paths. I resorted to 
simply hard codeing them in the path for windows 2k.
Is this no longer supported? 

Esp since 229584 seems closed wi works for me.

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

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


From noreply@sourceforge.net  Fri May  4 03:56:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 May 2001 19:56:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-421212 ] PythonPath registry value ignored in Py2
Message-ID: <E14vVm2-0005qu-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Mark Hammond (mhammond)
Summary: PythonPath registry value ignored in Py2

Initial Comment:
The difference I see between this and 229584
is that there are subkeys under ..\2.1\PythonPath
as I installed win32extensions (bld 139).

I still cannot pick up these paths. I resorted to 
simply hard codeing them in the path for windows 2k.
Is this no longer supported? 

Esp since 229584 seems closed wi works for me.

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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-03 19:56

Message:
Logged In: YES 
user_id=31435

Assigned to Mark.  Unclear what this is about, or even 
what "Py2" means.

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

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


From noreply@sourceforge.net  Fri May  4 07:54:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 03 May 2001 23:54:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-421250 ] os.execvp fails with empty argument list
Message-ID: <E14vZTk-0001Yc-00@usw-sf-web3.sourceforge.net>

Bugs item #421250, was updated on 2001-05-03 23:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421250&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Scharf (scharf)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.execvp fails with empty argument list

Initial Comment:
This code fails with python 2.1 (it's ok with 1.5):
python -c 'import os;  os.execvp("ls",[])'



Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/Tools/Python-2.1/lib/python2.1/os.py", line
291, in execvp
    _execvpe(file, args)
  File "/Tools/Python-2.1/lib/python2.1/os.py", line
341, in _execvpe
    apply(func, (fullname,) + argrest)
ValueError: execv() arg 2 must not be empty


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

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


From noreply@sourceforge.net  Fri May  4 08:12:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 00:12:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-421250 ] os.execvp fails with empty argument list
Message-ID: <E14vZkv-0002bB-00@usw-sf-web1.sourceforge.net>

Bugs item #421250, was updated on 2001-05-03 23:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421250&group_id=5470

Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Michael Scharf (scharf)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.execvp fails with empty argument list

Initial Comment:
This code fails with python 2.1 (it's ok with 1.5):
python -c 'import os;  os.execvp("ls",[])'



Traceback (most recent call last):
  File "<string>", line 1, in ?
  File "/Tools/Python-2.1/lib/python2.1/os.py", line
291, in execvp
    _execvpe(file, args)
  File "/Tools/Python-2.1/lib/python2.1/os.py", line
341, in _execvpe
    apply(func, (fullname,) + argrest)
ValueError: execv() arg 2 must not be empty


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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-04 00:12

Message:
Logged In: YES 
user_id=31435

Not a bug.  This is explained in the docs.  The argument 
list cannot be empty because the first entry is passed to 
the program as the program's name (argv[0], in C terms).  
Try execvp("ls",["ls"]) if you want ls to believe its name 
is "ls".


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

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


From noreply@sourceforge.net  Fri May  4 09:55:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 01:55:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-417418 ] Python 2.1 compile error on HPUX
Message-ID: <E14vbN4-0004E1-00@usw-sf-web1.sourceforge.net>

Bugs item #417418, was updated on 2001-04-19 11:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 compile error on HPUX

Initial Comment:
Compiling Python2.1 on HPUX11.0 gives the following 
errors:

cc: "Modules/termios.c", line 529: error 
1588: "VREPRINT" undefined.
cc: "Modules/termios.c", line 529: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 530: error 
1588: "VDISCARD" undefined.
cc: "Modules/termios.c", line 530: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 747: error 1588: "MDCD" 
undefined.
cc: "Modules/termios.c", line 747: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 750: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 753: error 1588: "MCTS" 
undefined.
cc: "Modules/termios.c", line 753: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 756: error 1588: "MDSR" 
undefined.
cc: "Modules/termios.c", line 756: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 759: error 1588: "MDTR" 
undefined.
cc: "Modules/termios.c", line 759: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 765: error 1588: "MRI" 
undefined.
cc: "Modules/termios.c", line 765: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 768: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 771: error 1588: "MRTS" 
undefined.
cc: "Modules/termios.c", line 771: error 1521: 
Incorrect initialization.


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

Comment By: Martin Jost (jost)
Date: 2001-05-04 01:55

Message:
Logged In: YES 
user_id=211439

The ones about M... (MCTS, MDTR, ...) are caused by the 
fact, that 
#include <sys/modem.h>
is needed for these on HPUX (10.20 at least) but not 
included.

But I found no fix for the V...-symbols


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-26 09:25

Message:
Logged In: NO 

The build also failes with HPUX B.10.20 A

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

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


From noreply@sourceforge.net  Fri May  4 12:11:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 04:11:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-420304 ] getattr function w/ default
Message-ID: <E14vdUU-0004eI-00@usw-sf-web2.sourceforge.net>

Bugs item #420304, was updated on 2001-04-30 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: getattr function w/ default

Initial Comment:
In Python 2.1, when calling the builtin getattr 
function and supplying the (optional) default 
argument, this default is returned on any exception 
raised during PyObject_GetAttr, even if the exception 
is not an AttributeError.  I did not expect this 
behavior after reading the getattr documentation.  Is 
this the  intended behavior?  (If so, I think the 
documentation should be made clearer on this point.)

Example (providing a non-string as the attribute name):

>>> class Test:
... 	pass
... 
>>> t = Test()
>>> getattr(t, 1, "hello")
'hello'
>>> 


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

Comment By: Michael Hudson (mwh)
Date: 2001-05-04 04:11

Message:
Logged In: YES 
user_id=6656

But consider this:

>>> getattr({},1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: attribute name must be string
>>> getattr({},1,"e")
'e'

or

>>> getattr(None,u"\343","e")
'e'
>>> getattr(None,u"\343")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII encoding error: ordinal not in range(128)

Here's a possible patch:

Index: bltinmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v
retrieving revision 2.200
diff -c -r2.200 bltinmodule.c
*** bltinmodule.c       2001/05/02 07:39:38     2.200
--- bltinmodule.c       2001/05/04 11:09:35
***************
*** 845,850 ****
--- 845,854 ----
  The globals and locals are dictionaries, defaulting to the
current\n\
  globals and locals.  If only globals is given, locals
defaults to it.";
  
+ /* Internal API needed by builtin_getattr(): */
+ extern 
+ PyObject *_PyUnicode_AsDefaultEncodedString(PyObject *unicode,
+                                 const char *errors);
  
  static PyObject *
  builtin_getattr(PyObject *self, PyObject *args)
***************
*** 854,859 ****
--- 858,874 ----
  
        if (!PyArg_ParseTuple(args, "OO|O:getattr", &v,
&name, &dflt))
                return NULL;
+       if (PyUnicode_Check(name)) {
+               name =
_PyUnicode_AsDefaultEncodedString(name, NULL);
+               if (name == NULL)
+                       return NULL;
+       } 
+       else if (!PyString_Check(name)) {
+               PyErr_Format(PyExc_TypeError,
+            "getattr: attribute name must be string, not
\%.500s\",
+                            name->ob_type->tp_name);
+               return NULL;
+       }
        result = PyObject_GetAttr(v, name);
        if (result == NULL && dflt != NULL) {
                PyErr_Clear();

... though by the time you've done all that, there's not
much point in calling PyObject_GetAttr at all...

OTOH, this changes behaviour, so maybe one should just
clarify this in the docs.

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

Comment By: Chris Cogdon (chriscog)
Date: 2001-05-03 17:55

Message:
Logged In: YES 
user_id=67116

Looks like an attribute error to me. consider this:

>>> getattr (t,fred,"thingy")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: There is no variable named 'fred'

Ie, in your own example, it couldn't find an attribute '1' 
in the class, even if its an integer attribute (which is 
only obtainable using getattr/setattr). That's exactly what 
AttributeError is

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

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


From noreply@sourceforge.net  Fri May  4 12:12:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 04:12:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-419462 ] python 2.0 compile fails on mandrake 8
Message-ID: <E14vdW6-0004gY-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Luke Kenneth Casson Leighton (lkcl)
Assigned to: Nobody/Anonymous (nobody)
Summary: python 2.0 compile fails on mandrake 8

Initial Comment:
bddbmodule fails to compile on mandrake 8.

if bdb is not a mandatory module, autoconf should be
used to
detect that bdb is or is not installed.  [it's looking
for
R_NEXT etc. which don't exist]

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

>Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-04 04:12

Message:
Logged In: YES 
user_id=80200

update: there is an option in the Modules setup which can be
used to explicity disable bddb.  however, this, i feel,
should be totally unnecessary.

why exactly, is autoconf used, when it cannot be told -
correctly -
not to use bddb?  i attempted a compile with --without-bddb
(or
whatever it was), and it still failed.  because there just
_happens_
to be a db.h file _somewhere_ on the system, the configure
test "assumes" that there is a valid bddb somewhere, which
there isn't.

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

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


From noreply@sourceforge.net  Fri May  4 12:17:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 04:17:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E14vdav-0004lE-00@usw-sf-web3.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-04 04:17

Message:
Logged In: YES 
user_id=80200

okay.  the forkingmixin code does a fork, records how many
children there are, and waits for one of them to exit,
before
proceeding - in particular, before proceeding to close
the request, etc.

... so why is not something similar done in ThreadingMixIn?

this kinda- tells me that thread-tracking is really needed,
in a similar way to that in forkingmixin.

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

Comment By: Gregory P. Smith (greg)
Date: 2001-05-03 16:26

Message:
Logged In: YES 
user_id=413

Just a note of another casualty of this bug: I had to add
the mentioned dummy close_request method hack to our own
ThreadingMixIn class in mojo nation (in the sourceforge
mojonation project's evil module, see the
common/MojoNationHTTPServer.py file).  Without it, python
2.1 would always raise an exception in the request handler
as soon as it tried to call self.connection.makefile()
because self.connection had apparently already been closed! 
(its fd was always -1)


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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-02 01:41

Message:
Logged In: YES 
user_id=80200

hi there mr jrielh,

thank you very much for the details.  what i am having a
little difficulty with is, what's the difference between
this and python 2.0 SocketServer.py?

more specifically, i'm looking at python 2.0 SocketServer.py
and, whilst i'm not a Threads expert, i see a t.start() but
no t.join().  i've been looking at the Queue example code in
the test method of threads.py, and start() is called on
every thread, followed by join() on every thread.  join
waits for the thread to finish, yes?

so... if that's the case, then python 2.0 SocketServer.py
should suffer from
exactly the same behaviour, yes?  unless python behaves
ever-so-slightly differently (timing issues?) when you have
an extra base class like this,
with the consequence that close_request() is more likely to
be called
before ThreadingMixIn.process_request().

?

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

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:20

Message:
Logged In: YES 
user_id=22448

This is related to bug #419873.
The problem is not specifically in the ThreadingMixin
specifically, but where BaseServer calls close_request()
after calling process_request().  In the threading mixin,
process_request() spins the thread and returns, causing the
request socket to be invalidated while the thread is still
running.  The fix given above will keep the socket valid
while the thread is running, but may cause the socket to not
close properly (my threads generally close the socket when
they are done anyway.)

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

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

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


From noreply@sourceforge.net  Fri May  4 15:41:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 07:41:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-418369 ] Typo in distutils (1.5 and 2.1)
Message-ID: <E14vglR-0001My-00@usw-sf-web1.sourceforge.net>

Bugs item #418369, was updated on 2001-04-23 14:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418369&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: A.M. Kuchling (akuchling)
Summary: Typo in distutils (1.5 and 2.1)

Initial Comment:
If README or README.txt are not specified in
doc_files, then bdist_rpm attempts to locate them. If
they exist, bdist_rpm adds them, erroneously, to
self.doc, instead of (correctly) to self.doc_files

self.doc does not exists, which then throws an
AttributeError

The offending code in Python 1.5 Distutils is
at or around line 192 of bdist_rpm.py

In Python 2.1 it is also at line 192 of bdist_rpm.py

Thanks!



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

Comment By: Jon Nelson (jnelson)
Date: 2001-05-04 07:41

Message:
Logged In: YES 
user_id=8446

Here is a patch:

diff -u -r
Distutils-1.0.1.orig/distutils/command/bdist_rpm.py
Distutils-1.0.1/d
istutils/command/bdist_rpm.py
--- Distutils-1.0.1.orig/distutils/command/bdist_rpm.py Fri
May  4 09:25:32 2001
+++ Distutils-1.0.1/distutils/command/bdist_rpm.py      Fri
May  4 09:26:12 2001
@@ -189,7 +189,7 @@
         if type(self.doc_files) is ListType:
             for readme in ('README', 'README.txt'):
                 if os.path.exists(readme) and readme not in
self.doc_files:
-                    self.doc.append(readme)
+                    self.doc_files.append(readme)
 
         self.ensure_string('release', "1")
         self.ensure_string('serial')   # should it be an
int?


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

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


From noreply@sourceforge.net  Fri May  4 16:08:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 08:08:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-421384 ] bad floating point precision
Message-ID: <E14vhBe-0001po-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bad floating point precision

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

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


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

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


From noreply@sourceforge.net  Fri May  4 20:04:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 12:04:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-421384 ] bad floating point precision
Message-ID: <E14vks4-0002df-00@usw-sf-web2.sourceforge.net>

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

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

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

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


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

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

Message:
Logged In: YES 
user_id=31435

This is not a bug.

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

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

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

>>> print 0.1+0.1
0.2
>>>

Follow the link for a detailed example:

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


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

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


From noreply@sourceforge.net  Fri May  4 22:10:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 14:10:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-419873 ] ThreadingTCPServer invalidating sockets
Message-ID: <E14vmqe-0004HV-00@usw-sf-web3.sourceforge.net>

Bugs item #419873, was updated on 2001-04-28 16:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419873&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ThreadingTCPServer invalidating sockets

Initial Comment:
running this:
import SocketServer

class TestServer(SocketServer.ThreadingTCPServer):
    def __init__(self, server_address,
RequestHandlerClass):
        SocketServer.ThreadingTCPServer.__init__(self,
server_address, RequestHandlerClass)
        self.quit = 0

    def process_request(self, request, client_address):
        print 'socket in process_request = %s' % request
        print 'id(socket) in process_request = %d' %
id(request)
       
SocketServer.ThreadingTCPServer.process_request(self,
request, client_address)

    def finish_request(self, request, client_address):
        print 'socket in finish_request = %s' % request
        print 'id(socket) in finish_request = %d' %
id(request)
        self.RequestHandlerClass(request,
client_address, self)
    
    def get_request(self):
        conn, addr = self.socket.accept()
        print 'socket in get_request = %s' % conn
        print 'id(socket) in get_request = %d' % id(conn)
        return conn,addr

if __name__ == '__main__':
    s = TestServer(('',9950),
SocketServer.BaseRequestHandler)
    s.handle_request()
    s.server_close()

results in the following output (when connected to
remotely):

socket in get_request = <socket object, fd=4, family=2,
type=1, protocol=0>
id(socket) in get_request = 135335216
socket in process_request = <socket object, fd=4,
family=2, type=1, protocol=0>
id(socket) in process_request = 135335216
socket in finish_request = <socket object, fd=-1,
family=2, type=1, protocol=0>
id(socket) in finish_request = 135335216

between in the thread-creation in process_request, the
socket's fd changes to -1.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-04 14:10

Message:
Logged In: NO 

Thanks, that solves the problem.

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

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:25

Message:
Logged In: YES 
user_id=22448

See comments for bug #417845.
BaseServer.handle_request() potentially (more like
consistently) calls close_request() before the thread spun
in process_request() is able to complete.  A work around is
shown in bug #417845 (overload close_request() to do nothing
instead of closing the socket.)

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

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


From noreply@sourceforge.net  Sat May  5 00:42:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 16:42:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-421533 ] testing for != with or
Message-ID: <E14vpDl-0001zj-00@usw-sf-web1.sourceforge.net>

Bugs item #421533, was updated on 2001-05-04 16:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421533&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: testing for != with or

Initial Comment:
#Windows98
#Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32

#please run this brief program:

s='ABCDE'
uneq=' != '
eq=' == '
t1='A'
t2='C'

# this loop works as expected
for char in s:
    if char != t1:
        print char + uneq + t1
    else:
        print char + eq + t1
        
print

# this loop NEVER prints eq?!?
for char in s:
    if char != t1 or char != t2:
        print char + uneq + t1 + ' or ' + t2
    else:
        print char + eq + t1 + ' or ' + t2

print

# this loop works as expected
for char in s:
    if char == t1 or char == t2:
        print char + eq + t1 + ' or ' + t2
    else:
        print char + uneq + t1 + ' or ' + t2

# end program

As you can see, when testing for inequality in the second loop, the correct branch in NEVER taken! The first loop shows != works, the third loop shows or works, but when they are combined the test is always true? Looks like maybe a parser error? (Just a guess)

Here is a sample output:
A == A
B != A
C != A
D != A
E != A

A != A or C # Big trouble here
B != A or C
C != A or C # and here
D != A or C
E != A or C

A == A or C
B != A or C
C == A or C
D != A or C
E != A or C


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

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


From noreply@sourceforge.net  Sat May  5 01:09:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 04 May 2001 17:09:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-421533 ] testing for != with or
Message-ID: <E14vpe2-0002Od-00@usw-sf-web1.sourceforge.net>

Bugs item #421533, was updated on 2001-05-04 16:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421533&group_id=5470

Category: None
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: testing for != with or

Initial Comment:
#Windows98
#Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32

#please run this brief program:

s='ABCDE'
uneq=' != '
eq=' == '
t1='A'
t2='C'

# this loop works as expected
for char in s:
    if char != t1:
        print char + uneq + t1
    else:
        print char + eq + t1
        
print

# this loop NEVER prints eq?!?
for char in s:
    if char != t1 or char != t2:
        print char + uneq + t1 + ' or ' + t2
    else:
        print char + eq + t1 + ' or ' + t2

print

# this loop works as expected
for char in s:
    if char == t1 or char == t2:
        print char + eq + t1 + ' or ' + t2
    else:
        print char + uneq + t1 + ' or ' + t2

# end program

As you can see, when testing for inequality in the second loop, the correct branch in NEVER taken! The first loop shows != works, the third loop shows or works, but when they are combined the test is always true? Looks like maybe a parser error? (Just a guess)

Here is a sample output:
A == A
B != A
C != A
D != A
E != A

A != A or C # Big trouble here
B != A or C
C != A or C # and here
D != A or C
E != A or C

A == A or C
B != A or C
C == A or C
D != A or C
E != A or C


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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-04 17:09

Message:
Logged In: YES 
user_id=31435

I can't imagine why you think this is a Python bug.  Given 
any character c whatsoever, at least one of (c != 'A') and 
(c != 'C') must be true, hence the "or" of those clauses 
must always be true.  In particular, when c is 'A' the c !
= 'C' clause is true, and when c is 'C' the c != 'A' clause 
is true.  You're getting exactly what you asked for, but 
that what you asked for is useless isn't Python's fault 
<wink>.

Perhaps you wanted "and" instead of "or"?


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

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


From noreply@sourceforge.net  Sat May  5 23:37:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 05 May 2001 15:37:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-421728 ] readline returns '' when interrupted
Message-ID: <E14wAfy-0005q8-00@usw-sf-web1.sourceforge.net>

Bugs item #421728, was updated on 2001-05-05 15:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421728&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline returns '' when interrupted

Initial Comment:
When file.readline() is waiting for a line to be read,
and is interrupted by a handled signal, it returns the
empty string, ''. It does not raise a IOError exception
(interrupted system call), as I would expect. Although
the documentation is not explicit about what the
behavior should be in this case, returning '' is a bad
idea since it looks just like an end of file, even
though there is more data that can be read.

There is some discussion of this in the python-list
mailing list -- the thread is "Signals and readline()".
In that thread, Jeff Epler advanced a theory as to a
possible source change to fix this.

It is easy to reproduce, and produces the same behavior
on both Linux (Mandrake 7.2) and FreeBSD (4.0). Using
Python 2.0.

To reproduce:

Enter this Python program interactively (under Unix):

import sys, os, signal
print os.getpid()
signal.signal(signal.SIGUSR2, lambda *x: None)
sys.stdin.readline()

>From another shell, send SIGUSR2 to the printed PID:

kill -SIGUSR2, <pid>

The readline will return ''.

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

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


From noreply@sourceforge.net  Sun May  6 21:12:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 06 May 2001 13:12:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-421878 ] File in a directory with a special chara
Message-ID: <E14wUtl-0003yq-00@usw-sf-web2.sourceforge.net>

Bugs item #421878, was updated on 2001-05-06 13:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421878&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gábor BORGULYA (borgulya)
Assigned to: Nobody/Anonymous (nobody)
Summary: File in a directory with a special chara

Initial Comment:
Using IDLE I tryed to save my work in the directory

C:\Documents and Settings\tdk.000\Dokumentumok\python\saját

but it failed:

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\program files\python21\lib\lib-tk\Tkinter.py", line 1285, in __call__
    return apply(self.func, args)
  File "C:\PROGRA~1\Python21\Tools\idle\IOBinding.py", line 145, in save_a_copy
    self.writefile(filename)
  File "C:\PROGRA~1\Python21\Tools\idle\IOBinding.py", line 152, in writefile
    f = open(filename, "w")
UnicodeError: ASCII encoding error: ordinal not in range(128)

After a log of tries I have renamed the directory: (sajat instead of saját)

C:\Documents and Settings\tdk.000\Dokumentumok\python\saját

and the file was finally saved.

I use WIN2000P.

I hope you can fix it.

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

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


From noreply@sourceforge.net  Mon May  7 06:29:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 06 May 2001 22:29:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-417418 ] Python 2.1 compile error on HPUX
Message-ID: <E14wdab-0000wW-00@usw-sf-web1.sourceforge.net>

Bugs item #417418, was updated on 2001-04-19 11:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 compile error on HPUX

Initial Comment:
Compiling Python2.1 on HPUX11.0 gives the following 
errors:

cc: "Modules/termios.c", line 529: error 
1588: "VREPRINT" undefined.
cc: "Modules/termios.c", line 529: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 530: error 
1588: "VDISCARD" undefined.
cc: "Modules/termios.c", line 530: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 747: error 1588: "MDCD" 
undefined.
cc: "Modules/termios.c", line 747: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 750: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 753: error 1588: "MCTS" 
undefined.
cc: "Modules/termios.c", line 753: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 756: error 1588: "MDSR" 
undefined.
cc: "Modules/termios.c", line 756: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 759: error 1588: "MDTR" 
undefined.
cc: "Modules/termios.c", line 759: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 765: error 1588: "MRI" 
undefined.
cc: "Modules/termios.c", line 765: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 768: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 771: error 1588: "MRTS" 
undefined.
cc: "Modules/termios.c", line 771: error 1521: 
Incorrect initialization.


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

Comment By: The Written Word (china) (tww-china)
Date: 2001-05-06 22:29

Message:
Logged In: YES 
user_id=119770

You can find a fix for this at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-417418.patch

You'll need to rerurn autoheader and autoconf before
testing.

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

Comment By: Martin Jost (jost)
Date: 2001-05-04 01:55

Message:
Logged In: YES 
user_id=211439

The ones about M... (MCTS, MDTR, ...) are caused by the 
fact, that 
#include <sys/modem.h>
is needed for these on HPUX (10.20 at least) but not 
included.

But I found no fix for the V...-symbols


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-26 09:25

Message:
Logged In: NO 

The build also failes with HPUX B.10.20 A

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

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


From noreply@sourceforge.net  Mon May  7 06:36:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 06 May 2001 22:36:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-416696 ] --with-threads fail for 2.1c2 on HPUX 11
Message-ID: <E14wdgn-00013M-00@usw-sf-web1.sourceforge.net>

Bugs item #416696, was updated on 2001-04-17 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416696&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Guido van Rossum (gvanrossum)
Summary: --with-threads fail for 2.1c2 on HPUX 11

Initial Comment:
 ./configure --with-thread --without-gcc
.
.
.
checking for --with-threads... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... no
checking for pthread_detach... yes
.
.
.
 make test
.
.
.
test_thread
test test_thread crashed -- thread.error: can't start
new thread                
.
.
.

4 tests failed: test_asynchat test_fork1 test_thread
test_threadedtempfile

-- 

The cause here is that at link time -lpthread is not
included.  If I manually relink with -lpthread, then no
tests fail tests pass.
113 tests
OK.                                                                   

-Harri

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

Comment By: The Written Word (china) (tww-china)
Date: 2001-05-06 22:36

Message:
Logged In: YES 
user_id=119770

You can find a patch to fix this against python 2.1 at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-416696.patch

You'll need to rerun autoconf to test.

This is a duplicate of bug #210665 (PR#360).

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

Comment By: Tim Peters (tim_one)
Date: 2001-04-19 15:16

Message:
Logged In: YES 
user_id=31435

Assigned to Guido.  Harri, can you supply a patch?  You 
seem to know what you're doing on this box, and nobody else 
does:  every release *something* about threads is broken on 
HPUX, and no patch submitted to date has ever cured this.  
No active Python developer runs HPUX, and I think we've all 
given up trying to sort out the conflicting claims of HP-UX 
users.


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

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


From noreply@sourceforge.net  Mon May  7 06:36:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 06 May 2001 22:36:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-210665 ] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <E14wdgy-0001zM-00@usw-sf-web2.sourceforge.net>

Bugs item #210665, was updated on 2000-07-31 14:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Initial Comment:
Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

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

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



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

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

Comment By: The Written Word (china) (tww-china)
Date: 2001-05-06 22:36

Message:
Logged In: YES 
user_id=119770

You can find a patch to fix this against python 2.1 at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-416696.patch

You'll need to rerun autoconf to test.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-02 08:38

Message:
Reopened because there's a dissenting opinion.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-02 07:25

Message:
Ok, check out the configure.in patch I created against Python 2.0:
  ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0.patch

I tested it under HP-UX 11.00 and it works just fine. The thread test worked too.

-- 
albert chin (china@thewrittenword.com)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-01 09:18

Message:
Ick! Why check for anything with __ prepended to the name? Isn't that like checking for a "hidden" function, which might not be there in a followup version?

On HP-UX 11.00, pthread_create is in /usr/lib/libc.sl anyway. The proper way to check for pthread_create is:
  AC_TRY_LINK([#include <pthread.h>

  void * start_routine (void *arg) { exit (0); }], [
  pthread_create (NULL, NULL, start_routine, NULL)], [
    AC_MSG_RESULT(yes)], [
    AC_MSG_RESULT(no)])

I modified configure.in in 2.0 to remove the patch you included in CVS 1.175 and added a test to include <pthread.h> similar to the above (linked without -lpthread and with -lpthread). I'm testing now. Will provide a patch when things are tested.

Also, I don't think threads on HP-UX 10.20 will work unless you have the DCE libraries installed. Anyhow, I'd probably avoid threads on 10.20.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-30 09:48

Message:
Philipp submitted a patch to configure.in that fixes the problem for him and doesn't look like it would break things for others.  configure.in, CVS revision 1.175.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 07:45

Message:
OK, so the correct thing to do seems to be to somehow add #include <pthread.h> to the tests for thread libraries. I'm afraid I won't be able to fix this in 2.0final, but I'll think about fixing it in 2.1 (or 2.0.1, whichever comes first :-).

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

Comment By: Eddy De Greef (edg)
Date: 2000-10-10 04:55

Message:
I can confirm that the bug still exists in 2.0c1.
It works fine on HP-UX 10.20 (which only has libcma),
but not on HP-UX 11 (which both has libcma and libpthread).
The pthread_create function is not defined as a macro though,
but as a static function:

static int pthread_create(pthread_t *tid, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg)
   { return(__pthread_create_system(tid, attr, start_routine, arg)); }

I don't see an easy way to work around this.
I'm not a configure expert, but perhaps the script should
first check whether this code compiles and links:

#include <pthread.h>
int main()
{
   pthread_create(0,0,0,0);
   return 0;
}

and if not, fall back on the other tests ?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-06 10:40

Message:
I have two reports from people for whom configure, build and run  with threads now works on HP-UX 10 and 11. I'm not sure what to do about this report... What's different on Philipp's system???

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-25 06:10

Message:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 02:56

Message:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:05

Message:
Please do triage on this bug.

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

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


From noreply@sourceforge.net  Mon May  7 09:20:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 01:20:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Unicode Build Prob.
Message-ID: <E14wgFS-0003az-00@usw-sf-web1.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Schinckel (schinckel)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Python for BeOS/PPC Unicode Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

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

>Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

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

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


From noreply@sourceforge.net  Mon May  7 10:39:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 02:39:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-421973 ] Coercion rules incomplete
Message-ID: <E14whUX-0004qY-00@usw-sf-web1.sourceforge.net>

Bugs item #421973, was updated on 2001-05-07 02:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421973&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Coercion rules incomplete

Initial Comment:
The description of the coercion rules for numeric types
at
http://www.python.org/doc/current/ref/numeric-types.html
is incomplete. Step 3 says "We only get here if neither
x nor y is a class instance. " But step 2a also refers
to step 3 for the case that an explicit coercion
function returns None. It is not clear what happens in
that case.


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

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


From noreply@sourceforge.net  Mon May  7 12:14:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 04:14:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Unicode Build Prob.
Message-ID: <E14wiyX-0005gG-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Schinckel (schinckel)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Python for BeOS/PPC Unicode Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

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

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

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

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

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


From noreply@sourceforge.net  Mon May  7 13:00:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 05:00:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-421999 ] wrong priority doc for ** vs unary -
Message-ID: <E14wjgd-0006FD-00@usw-sf-web3.sourceforge.net>

Bugs item #421999, was updated on 2001-05-07 05:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421999&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: wrong priority doc for ** vs unary -

Initial Comment:
http://www.python.org/doc/current/ref/summary.html 
documents ** as higher-priority than unary - (by 
placing it in the following line on the precedence 
table).  This is unfortunately false: ** is higher 
priority, so e.g. -2**2 evaluates to -4.  Alas, and 
quite confusing to newbies, but at least it needs to 
be documented right.


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

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


From noreply@sourceforge.net  Mon May  7 13:52:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 05:52:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-422004 ] Missing "fixup" for "exceptions" module
Message-ID: <E14wkVP-0007KB-00@usw-sf-web2.sourceforge.net>

Bugs item #422004, was updated on 2001-05-07 05:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422004&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jürgen Hermann (jhermann)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing "fixup" for "exceptions" module

Initial Comment:
The following call is missing in Py_Initialize():

*** pythonrun.c,1       Mon May  7 14:41:29 2001
--- pythonrun.c Mon May  7 14:42:39 2001
***************
*** 147,152 ****
--- 147,153 ----
 
        /* phase 2 of builtins */
        _PyImport_FixupExtension
("__builtin__", "__builtin__");
+       _PyImport_FixupExtension
("exceptions", "exceptions");
 
        initsigs(); /* Signal handling stuff, 
including initintr() */           

Without this patch, you might get this exception:

Traceback (most recent call last):
  File "/export/home/jhe/ns/httpd-
8332.195.226.107.82/cgi-bin/extest.py", line 1, in ?
    import exceptions
ImportError: Cannot re-init internal module 
exceptions                          

This bug was probably introduced when exception.py 
became a built-in extension module. Applies to both 
2.0 and 2.1 code.

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

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


From noreply@sourceforge.net  Mon May  7 13:56:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 05:56:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-422004 ] Missing "fixup" for "exceptions" module
Message-ID: <E14wkYx-0007Nz-00@usw-sf-web2.sourceforge.net>

Bugs item #422004, was updated on 2001-05-07 05:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422004&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jürgen Hermann (jhermann)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Missing "fixup" for "exceptions" module

Initial Comment:
The following call is missing in Py_Initialize():

*** pythonrun.c,1       Mon May  7 14:41:29 2001
--- pythonrun.c Mon May  7 14:42:39 2001
***************
*** 147,152 ****
--- 147,153 ----
 
        /* phase 2 of builtins */
        _PyImport_FixupExtension
("__builtin__", "__builtin__");
+       _PyImport_FixupExtension
("exceptions", "exceptions");
 
        initsigs(); /* Signal handling stuff, 
including initintr() */           

Without this patch, you might get this exception:

Traceback (most recent call last):
  File "/export/home/jhe/ns/httpd-
8332.195.226.107.82/cgi-bin/extest.py", line 1, in ?
    import exceptions
ImportError: Cannot re-init internal module 
exceptions                          

This bug was probably introduced when exception.py 
became a built-in extension module. Applies to both 
2.0 and 2.1 code.

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

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


From noreply@sourceforge.net  Mon May  7 19:25:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 11:25:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-422088 ] string.replace()
Message-ID: <E14wph3-0003du-00@usw-sf-web2.sourceforge.net>

Bugs item #422088, was updated on 2001-05-07 11:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422088&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Casado (martin_casado)
Assigned to: Nobody/Anonymous (nobody)
Summary: string.replace()

Initial Comment:
>>> import sys
>>> sys.version
'2.0c1 (#7, Jan 24 2001, 15:36:12) [C]'
>>> s = "123"
>>> s.replace("123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError
>>> os.uname()
('OSF1', 'xxx', 'V4.0', '1229', 'alpha')
>>> 


I haven't tried it with anything newer, perhaps this
bug
has already been posted and/or fixed, though I couldn't
find it in the buglist

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

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


From noreply@sourceforge.net  Mon May  7 21:13:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 13:13:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-422108 ] Error in rich comparisons
Message-ID: <E14wrOI-00056K-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Error in rich comparisons

Initial Comment:
try_rich_to_3way_compare is documented as returning -2 
for an exception.  However, in the loop, when 
try_rich_compare_bool returns -1, 
try_rich_to_3way_compare returns -1 instead of -2.  
try_rich_compare_bool does return -1 in case of 
exception.

Unclear whether this is a bug in the code or the 
comment.  The only caller of try_rich_to_3way_compare 
is do_cmp, and the latter's return conditions aren't 
documented, although at least one of do_cmp's callers 
documents its own return conditions as "-2 for an 
exception" too.

So best guess is that the code is in error, and 
that "return -1" should be replaced by "return -2" in 
try_rich_to_3way_compare.


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

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


From noreply@sourceforge.net  Mon May  7 21:33:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 13:33:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-422108 ] Error in rich comparisons
Message-ID: <E14wrhO-0004kC-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Error in rich comparisons

Initial Comment:
try_rich_to_3way_compare is documented as returning -2 
for an exception.  However, in the loop, when 
try_rich_compare_bool returns -1, 
try_rich_to_3way_compare returns -1 instead of -2.  
try_rich_compare_bool does return -1 in case of 
exception.

Unclear whether this is a bug in the code or the 
comment.  The only caller of try_rich_to_3way_compare 
is do_cmp, and the latter's return conditions aren't 
documented, although at least one of do_cmp's callers 
documents its own return conditions as "-2 for an 
exception" too.

So best guess is that the code is in error, and 
that "return -1" should be replaced by "return -2" in 
try_rich_to_3way_compare.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-07 13:33

Message:
Logged In: NO 

Yup, looks right.  Go for it.

--Guido


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

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


From noreply@sourceforge.net  Mon May  7 21:54:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 13:54:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-422108 ] Error in rich comparisons
Message-ID: <E14ws1u-0007h0-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: Error in rich comparisons

Initial Comment:
try_rich_to_3way_compare is documented as returning -2 
for an exception.  However, in the loop, when 
try_rich_compare_bool returns -1, 
try_rich_to_3way_compare returns -1 instead of -2.  
try_rich_compare_bool does return -1 in case of 
exception.

Unclear whether this is a bug in the code or the 
comment.  The only caller of try_rich_to_3way_compare 
is do_cmp, and the latter's return conditions aren't 
documented, although at least one of do_cmp's callers 
documents its own return conditions as "-2 for an 
exception" too.

So best guess is that the code is in error, and 
that "return -1" should be replaced by "return -2" in 
try_rich_to_3way_compare.


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

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

Message:
Logged In: YES 
user_id=31435

Fixed in Objects/object.c, new revision: 2.130.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-07 13:33

Message:
Logged In: NO 

Yup, looks right.  Go for it.

--Guido


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

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


From noreply@sourceforge.net  Mon May  7 22:12:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 14:12:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-422121 ] Insecurities in dict comparison
Message-ID: <E14wsJA-0005sw-00@usw-sf-web2.sourceforge.net>

Bugs item #422121, was updated on 2001-05-07 14:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422121&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: Insecurities in dict comparison

Initial Comment:
Dict comparison is complicated, and the comparison 
code holds on to pointers to keys and values 
across "dangerous" calls without incrementing 
refcounts first.  For example, characterize() hangs on 
to each key across two calls to 
PyObject_RichCompareBool() and one to PyDict_GetItem
(), and any of those could call back into Python code 
and delete key in the meantime.  Unref'ed pointers to 
a key and a value may also be passed back to 
characterize()'s caller.  dict_compare() can hold on 
to these passed-back pointers across calls to 
PyObject_Compare() too.

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

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


From noreply@sourceforge.net  Tue May  8 02:09:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 18:09:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-422177 ] Results from .pyc differs from .py
Message-ID: <E14ww0i-0000Nt-00@usw-sf-web2.sourceforge.net>

Bugs item #422177, was updated on 2001-05-07 18:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422177&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Results from .pyc differs from .py

Initial Comment:
Guido, the following is from c.l.py.  It *seems* to be 
due to marshal using damagingly low precision for 
float->string conversion.  If you don't object to my 
fixing it, assign this back to me.  But I'll still be 
baffled by why the .py result differs from the .pyc 
result (which I reproduced under current CVS, under 
Windows):


-----Original Message-----
From: python-list-admin@python.org
On Behalf Of Scott Ransom
Sent: Monday, May 07, 2001 4:27 PM
To: python-list@python.org
Cc: Scott Ransom
Subject: Variables different between .py and .pyc


Hello,

I'm running Python 2.0 on Linux and seem to have found
a strange problem when importing floating point
variables defined in modules.  I have not
tried this in Python 2.1 so I don't know if the
problem exists there as well.

Here is a simple module (vars.py):

PI    = 3.14159265358979324
TWOPI = 6.28318530717958648

When I import this and check the variable values here
is what I get:

presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535897931, 6.2831853071795862)

All is well, so far.  Now, if I try again (and this
time the interpreter loads from the newly created
vars.pyc file):

presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535900001, 6.2831853071800001)

My variables are truncated at ~12 decimal points of
precision.

Removing the .pyc file makes things "better" again...

presto:~$ rm vars.pyc
presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535897931, 6.2831853071795862)

...


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

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


From noreply@sourceforge.net  Tue May  8 03:58:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 19:58:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-422088 ] [OSF1 alpha] string.replace()
Message-ID: <E14wxhk-000513-00@usw-sf-web1.sourceforge.net>

Bugs item #422088, was updated on 2001-05-07 11:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422088&group_id=5470

>Category: Python Interpreter Core
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Casado (martin_casado)
Assigned to: Nobody/Anonymous (nobody)
>Summary: [OSF1 alpha] string.replace()

Initial Comment:
>>> import sys
>>> sys.version
'2.0c1 (#7, Jan 24 2001, 15:36:12) [C]'
>>> s = "123"
>>> s.replace("123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError
>>> os.uname()
('OSF1', 'xxx', 'V4.0', '1229', 'alpha')
>>> 


I haven't tried it with anything newer, perhaps this
bug
has already been posted and/or fixed, though I couldn't
find it in the buglist

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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-07 19:58

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try recompiling with optimization 
turned off.  If that makes the problem go away (seems 
likely to me), it's a platform compiler bug.

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

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


From noreply@sourceforge.net  Tue May  8 05:05:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:05:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-422177 ] Results from .pyc differs from .py
Message-ID: <E14wykm-0001uW-00@usw-sf-web3.sourceforge.net>

Bugs item #422177, was updated on 2001-05-07 18:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422177&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Results from .pyc differs from .py

Initial Comment:
Guido, the following is from c.l.py.  It *seems* to be 
due to marshal using damagingly low precision for 
float->string conversion.  If you don't object to my 
fixing it, assign this back to me.  But I'll still be 
baffled by why the .py result differs from the .pyc 
result (which I reproduced under current CVS, under 
Windows):


-----Original Message-----
From: python-list-admin@python.org
On Behalf Of Scott Ransom
Sent: Monday, May 07, 2001 4:27 PM
To: python-list@python.org
Cc: Scott Ransom
Subject: Variables different between .py and .pyc


Hello,

I'm running Python 2.0 on Linux and seem to have found
a strange problem when importing floating point
variables defined in modules.  I have not
tried this in Python 2.1 so I don't know if the
problem exists there as well.

Here is a simple module (vars.py):

PI    = 3.14159265358979324
TWOPI = 6.28318530717958648

When I import this and check the variable values here
is what I get:

presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535897931, 6.2831853071795862)

All is well, so far.  Now, if I try again (and this
time the interpreter loads from the newly created
vars.pyc file):

presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535900001, 6.2831853071800001)

My variables are truncated at ~12 decimal points of
precision.

Removing the .pyc file makes things "better" again...

presto:~$ rm vars.pyc
presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535897931, 6.2831853071795862)

...


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

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

Message:
Logged In: YES 
user_id=31435

I'm attaching a patch so people can try the fix x-
platform.  You need a current CVS Python (one with 
test/double_const.py) first.

If you apply *just* the test_import.py part of this patch, 
then I expect test_import to fail if and only if 
double_const.pyc exists.

After the whole patch, I expect test_import never to fail.  
But x-platform FP stuff is tricky, so I'd like a little x-
plat pre-testing before risking a checkin.  Works fine 
under Windows, of course. 

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

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


From noreply@sourceforge.net  Tue May  8 05:10:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:10:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-418977 ] Access Violation in PyCell_Set
Message-ID: <E14wyp5-0006C9-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Greg Chapman (glchapman)
Assigned to: Jeremy Hylton (jhylton)
Summary: Access Violation in PyCell_Set

Initial Comment:
While stepping through a program using the Pythonwin 
debugger, I got an access violation which appears to 
be taking place in PyCell_Set (I'm not using the debug 
libraries).  Specifically, it appears that the op 
parameter is NULL, so the PyCell_Check(op) results in 
the AV.  I believe the call stack at this point was:

  PyCell_Set
  dict_to_map
  PyFrame_LocalsToFast (line 366 of frameobject.c?)
  call_trace
  SET_LINENO (case of eval_code2)

Please let me know if it would be helpful to see the 
python file I was stepping through and I'll upload it.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-07 21:10

Message:
Logged In: YES 
user_id=31392

Martin's patch applied in rev 2.50 of frameobject.c.
This patch should go in a 2.1.1 release.


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

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 08:51

Message:
Logged In: YES 
user_id=21627

There is a patch for this bug in
http://sourceforge.net/tracker/index.php?func=detail&aid=419176&group_id=5470&atid=305470

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 08:46

Message:
Logged In: YES 
user_id=21627

It turns out that the error is caused by the tracing. The
example t2.py will cause this error in Python 2.1 even
without running under a debugger.

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

Comment By: Greg Chapman (glchapman)
Date: 2001-04-26 05:19

Message:
Logged In: YES 
user_id=86307

As requested, I've stripped down the code to a fairly 
simple test case.  There's a comment indicating the line on 
which the AV occurs (it occurs when you press the key to 
single step off that line to the next).  No AV occurs if 
you simply run the script under PythonWin.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-26 00:19

Message:
Logged In: YES 
user_id=21627

I think it would be definitely helpful to see the sources;
it would be even better if you could reduce them to a small
test case. Please attach them to this report.

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

Comment By: Greg Chapman (glchapman)
Date: 2001-04-25 15:29

Message:
Logged In: YES 
user_id=86307

I apologize -- I forgot to add that I'm using Python 2.1 
final (binaries downloaded from Sourceforge) and the latest 
win32_all binaries under Windows 2000.

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

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


From noreply@sourceforge.net  Tue May  8 05:22:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:22:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-422121 ] Insecurities in dict comparison
Message-ID: <E14wz10-0002ez-00@usw-sf-web2.sourceforge.net>

Bugs item #422121, was updated on 2001-05-07 14:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422121&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: Insecurities in dict comparison

Initial Comment:
Dict comparison is complicated, and the comparison 
code holds on to pointers to keys and values 
across "dangerous" calls without incrementing 
refcounts first.  For example, characterize() hangs on 
to each key across two calls to 
PyObject_RichCompareBool() and one to PyDict_GetItem
(), and any of those could call back into Python code 
and delete key in the meantime.  Unref'ed pointers to 
a key and a value may also be passed back to 
characterize()'s caller.  dict_compare() can hold on 
to these passed-back pointers across calls to 
PyObject_Compare() too.

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

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


From noreply@sourceforge.net  Tue May  8 05:23:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:23:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-420216 ] bad links in v2.1 docs
Message-ID: <E14wz21-0002fg-00@usw-sf-web2.sourceforge.net>

Bugs item #420216, was updated on 2001-04-30 11:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420216&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Griffin (dspguru)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bad links in v2.1 docs

Initial Comment:
The file 'module-imap.html' is linked, but not 
supplied (see grep at bottom).

Also, there are several links to "about.html" in 
the "doc\dist" directory.  However, no "about.html" is 
supplied there.

Thanks!

=g2

----------------
F:\apps\Python21\Doc>grep -d+ module-imap.html *.html
File lib\module-poplib.html:
using the <tt class='module'><a href='module-
IMAP.html'>IMAP</a></tt> class, as
IMAP servers tend to be better
File lib\pop3-objects.html:
    <dt>Module <b><tt class='module'><a href='module-
imap.html'>imap</a></tt>:</
b>

F:\apps\Python21\Doc>dir module-imap.html /s
 Volume in drive F has no label.
 Volume Serial Number is 

File Not Found

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

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


From noreply@sourceforge.net  Tue May  8 05:24:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:24:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-420343 ] SystemError from tuple() builtin
Message-ID: <E14wz2e-0002gK-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Greg Chapman (glchapman)
>Assigned to: Thomas Wouters (twouters)
Summary: SystemError from tuple() builtin

Initial Comment:
The following produces a SystemError under Python 2.1:

>>> class Test:
... 	def __init__(self):
... 		self.list = [1]
... 	def __len__(self):
... 		return 0
... 	def __getitem__(self, index):
... 		return self.list[index]
... 
>>> t = Test()
>>> tuple(t)
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
SystemError: C:\USERS\greg\PROG\CPP\PYTHON\Python-2.1
\Objects\tupleobject.c:506: bad argument to internal 
function

The problem is the call made by PySequence_Tuple to 
_PyTuple_Resize.  The above code results in an attempt 
to resize the empty tuple, the ref count of which is 
greater than 1.




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

Comment By: Greg Chapman (glchapman)
Date: 2001-04-30 19:41

Message:
Logged In: YES 
user_id=86307

Apropos this report and the recent python-dev 
thread "Iterators, map, xreadlines and docs":

>>> f = open(r"c:\autoexec.bat")
>>> l = list(f.xreadlines())
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: len() of unsized object

Admittedly, using xreadlines like this is silly, but it 
probably ought to work.  Both PySequence_Tuple and 
PySequence_List require len() (PySequence_Size) to succeed, 
even though they then pretty much ignore the returned 
length.  Perhaps they should be changed to be consistent 
with the changes in map.


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

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


From noreply@sourceforge.net  Tue May  8 05:24:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:24:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-420490 ] lookdict_string does not use interning
Message-ID: <E14wz39-0002gZ-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Tim Peters (tim_one)
Summary: lookdict_string does not use interning

Initial Comment:
In Python 2.1, when a dictionary uses lookdict_string 
to retrieve items, the function used to compare 
strings is PyString_Type.tp_compare, i.e. 
string_compare.  string_compare does not check if its 
parameters are actually the same PStringObject *, so 
an actual string comparison is made even if the 
dictionary's keys have been interned.  Python 1.52 
used PyObject_Compare to compare all keys, and this 
function did check to see if its parameters were the 
same PyObject *.

I wonder if this might be one source of the slow-down 
in Python 2.1?


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

Comment By: Greg Chapman (glchapman)
Date: 2001-05-01 10:20

Message:
Logged In: YES 
user_id=86307

Actually, I apologize for wasting everyone's time.  This 
report is totally false; I missed this line:

	if (ep->me_key == NULL || ep->me_key == key)
		return ep;

Please ignore this.  I'm going to go get some sleep.



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

Comment By: Greg Chapman (glchapman)
Date: 2001-05-01 10:17

Message:
Logged In: YES 
user_id=86307

Actually, to be more specific, only the first comparison in 
lookdict_string forgets to see if the string pointers are 
the same.  I assume the proper fix would be to change this 
first comparison to be:

 	if (ep->me_key == dummy)
 		freeslot = ep;
 	else {
-		if (ep->me_hash == hash
-		    && compare(ep->me_key, key) == 0) {
+		if (ep->me_key == key
+                    || (ep->me_hash == hash
+		    && compare(ep->me_key, key) == 0)) {
 			return ep;
 		}
 		freeslot = NULL;
 	}


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

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


From noreply@sourceforge.net  Tue May  8 05:26:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:26:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-420304 ] getattr function w/ default
Message-ID: <E14wz54-0002iB-00@usw-sf-web2.sourceforge.net>

Bugs item #420304, was updated on 2001-04-30 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Greg Chapman (glchapman)
>Assigned to: Jeremy Hylton (jhylton)
Summary: getattr function w/ default

Initial Comment:
In Python 2.1, when calling the builtin getattr 
function and supplying the (optional) default 
argument, this default is returned on any exception 
raised during PyObject_GetAttr, even if the exception 
is not an AttributeError.  I did not expect this 
behavior after reading the getattr documentation.  Is 
this the  intended behavior?  (If so, I think the 
documentation should be made clearer on this point.)

Example (providing a non-string as the attribute name):

>>> class Test:
... 	pass
... 
>>> t = Test()
>>> getattr(t, 1, "hello")
'hello'
>>> 


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-07 21:26

Message:
Logged In: YES 
user_id=31392

This looks like a bug to me, too.  I think a non-string attr
argument
to getattr()  should raise TypeError.


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

Comment By: Michael Hudson (mwh)
Date: 2001-05-04 04:11

Message:
Logged In: YES 
user_id=6656

But consider this:

>>> getattr({},1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: attribute name must be string
>>> getattr({},1,"e")
'e'

or

>>> getattr(None,u"\343","e")
'e'
>>> getattr(None,u"\343")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII encoding error: ordinal not in range(128)

Here's a possible patch:

Index: bltinmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v
retrieving revision 2.200
diff -c -r2.200 bltinmodule.c
*** bltinmodule.c       2001/05/02 07:39:38     2.200
--- bltinmodule.c       2001/05/04 11:09:35
***************
*** 845,850 ****
--- 845,854 ----
  The globals and locals are dictionaries, defaulting to the
current\n\
  globals and locals.  If only globals is given, locals
defaults to it.";
  
+ /* Internal API needed by builtin_getattr(): */
+ extern 
+ PyObject *_PyUnicode_AsDefaultEncodedString(PyObject *unicode,
+                                 const char *errors);
  
  static PyObject *
  builtin_getattr(PyObject *self, PyObject *args)
***************
*** 854,859 ****
--- 858,874 ----
  
        if (!PyArg_ParseTuple(args, "OO|O:getattr", &v,
&name, &dflt))
                return NULL;
+       if (PyUnicode_Check(name)) {
+               name =
_PyUnicode_AsDefaultEncodedString(name, NULL);
+               if (name == NULL)
+                       return NULL;
+       } 
+       else if (!PyString_Check(name)) {
+               PyErr_Format(PyExc_TypeError,
+            "getattr: attribute name must be string, not
\%.500s\",
+                            name->ob_type->tp_name);
+               return NULL;
+       }
        result = PyObject_GetAttr(v, name);
        if (result == NULL && dflt != NULL) {
                PyErr_Clear();

... though by the time you've done all that, there's not
much point in calling PyObject_GetAttr at all...

OTOH, this changes behaviour, so maybe one should just
clarify this in the docs.

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

Comment By: Chris Cogdon (chriscog)
Date: 2001-05-03 17:55

Message:
Logged In: YES 
user_id=67116

Looks like an attribute error to me. consider this:

>>> getattr (t,fred,"thingy")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: There is no variable named 'fred'

Ie, in your own example, it couldn't find an attribute '1' 
in the class, even if its an integer attribute (which is 
only obtainable using getattr/setattr). That's exactly what 
AttributeError is

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

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


From noreply@sourceforge.net  Tue May  8 05:28:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:28:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-416573 ] makesockaddr() AF_UNIX ignores sun_len
Message-ID: <E14wz6t-0002jW-00@usw-sf-web2.sourceforge.net>

Bugs item #416573, was updated on 2001-04-16 18:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416573&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: makesockaddr() AF_UNIX ignores sun_len

Initial Comment:
On FreeBSD 4.2-RELEASE, bind two AF_UNIX,SOCK_DGRAM
sockets and send a packet over.  The recvfrom() call
returns a corrupted pathname.

This seems to fix the problem:

return PyString_FromStringAndSize (a->sun_path,
a->sun_len - (sizeof a->sun_len + sizeof
a->sun_family));

Another fix would be to zero out the address buffer in
recvfrom() [and any other places that call
makesockaddr]

-Sam


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

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


From noreply@sourceforge.net  Tue May  8 05:27:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:27:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-419390 ] base64.py could be smarter...
Message-ID: <E14wz6E-0002iu-00@usw-sf-web2.sourceforge.net>

Bugs item #419390, was updated on 2001-04-26 23:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419390&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: base64.py could be smarter...

Initial Comment:
base64.encodestring and decodestring take the
provided string, wrap it in a StringIO, then 
pass it to encode/decode which uses read() to 
pull it back out again. 

Seems pretty inefficient.

Replacing decodestring with:
  return binascii.a2b_base64(s)

results in a speedup of a factor of 16 or so.
(my sample: a 2Mb encoded voice message - takes
an average of 10s in the current form, and 0.6s
using just binascii.)

A similar speedup for encodestring seems possible.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-07 21:27

Message:
Logged In: YES 
user_id=31392

Anthony,
Could you submit a patch?


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

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


From noreply@sourceforge.net  Tue May  8 05:33:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:33:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-420502 ] seek/tell beyond eof without exceptions
Message-ID: <E14wzBs-0002mx-00@usw-sf-web2.sourceforge.net>

Bugs item #420502, was updated on 2001-05-01 10:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420502&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Grzegorz Makarewicz (mpmak)
Assigned to: Nobody/Anonymous (nobody)
Summary: seek/tell beyond eof without exceptions

Initial Comment:

Methods from FileObject like seek/tell doesn`t check 
for errno value. The result is that python exceptions 
aren`t throwned.

Small example:

import sys
SEEK_END = 2

def main():
	fp=open(sys.argv[0],'rb')
	fp.seek(0,SEEK_END)
	off = fp.tell()
	fp.seek(off,SEEK_END)
	x = fp.tell()
	print 'tell?',x

main()


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-07 21:33

Message:
Logged In: YES 
user_id=31392

The seek and tell methods do check the return value and
raise
an exception if the C function returns an error.  I don't
believe
a seek call will fail merely because it seeks beyond the end
of a file.

If you've got a legit bug, please include a C program that
demonstrates the correct behavior.


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

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


From noreply@sourceforge.net  Tue May  8 05:55:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 21:55:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-422121 ] Insecurities in dict comparison
Message-ID: <E14wzWt-00031Z-00@usw-sf-web2.sourceforge.net>

Bugs item #422121, was updated on 2001-05-07 14:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422121&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Tim Peters (tim_one)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Insecurities in dict comparison

Initial Comment:
Dict comparison is complicated, and the comparison 
code holds on to pointers to keys and values 
across "dangerous" calls without incrementing 
refcounts first.  For example, characterize() hangs on 
to each key across two calls to 
PyObject_RichCompareBool() and one to PyDict_GetItem
(), and any of those could call back into Python code 
and delete key in the meantime.  Unref'ed pointers to 
a key and a value may also be passed back to 
characterize()'s caller.  dict_compare() can hold on 
to these passed-back pointers across calls to 
PyObject_Compare() too.

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

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

Message:
Logged In: YES 
user_id=31435

Unassigned again, because I don't expect to get to this in 
the foreseeable future (if I thought I would, I would have 
assigned it to me when I entered it).


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

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


From noreply@sourceforge.net  Tue May  8 06:01:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 22:01:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-420343 ] SystemError from tuple() builtin
Message-ID: <E14wzcb-00035j-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Greg Chapman (glchapman)
Assigned to: Thomas Wouters (twouters)
Summary: SystemError from tuple() builtin

Initial Comment:
The following produces a SystemError under Python 2.1:

>>> class Test:
... 	def __init__(self):
... 		self.list = [1]
... 	def __len__(self):
... 		return 0
... 	def __getitem__(self, index):
... 		return self.list[index]
... 
>>> t = Test()
>>> tuple(t)
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
SystemError: C:\USERS\greg\PROG\CPP\PYTHON\Python-2.1
\Objects\tupleobject.c:506: bad argument to internal 
function

The problem is the call made by PySequence_Tuple to 
_PyTuple_Resize.  The above code results in an attempt 
to resize the empty tuple, the ref count of which is 
greater than 1.




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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-07 22:01

Message:
Logged In: YES 
user_id=31435

Greg, list(f.xreadlines()) happens to work already under 
current CVS Python.  But note for the future that attaching 
a feature request to an unrelated bug report is a low-
probability way to get anyone to notice ...

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

Comment By: Greg Chapman (glchapman)
Date: 2001-04-30 19:41

Message:
Logged In: YES 
user_id=86307

Apropos this report and the recent python-dev 
thread "Iterators, map, xreadlines and docs":

>>> f = open(r"c:\autoexec.bat")
>>> l = list(f.xreadlines())
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: len() of unsized object

Admittedly, using xreadlines like this is silly, but it 
probably ought to work.  Both PySequence_Tuple and 
PySequence_List require len() (PySequence_Size) to succeed, 
even though they then pretty much ignore the returned 
length.  Perhaps they should be changed to be consistent 
with the changes in map.


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

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


From noreply@sourceforge.net  Tue May  8 06:15:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 22:15:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-422203 ] math.sqrt() broken on parisc-linux
Message-ID: <E14wzql-0002iR-00@usw-sf-web3.sourceforge.net>

Bugs item #422203, was updated on 2001-05-07 22:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422203&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: dann frazier (dannf)
Assigned to: Nobody/Anonymous (nobody)
Summary: math.sqrt() broken on parisc-linux

Initial Comment:
python 2.0
Debian GNU/Linux on PA-RISC
package: python2-base_2.0-7

for any integer x, math.sqrt(x.0) seems to equal 0.0

----
sebadoh:/tmp# python2
Python 2.0 (#0, Apr 27 2001, 03:16:35) 
[GCC 3.0 20010315 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import math
>>> math.sqrt(2.0)
0.0
>>> math.sqrt(2)
1.4142135623730951
----

the C equivalent (math.h) reports the correct answer.

sebadoh:/tmp# uname -a
Linux sebadoh 2.4.0 #1 Mon May 7 12:41:27 MDT 2001
parisc unknown


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

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


From noreply@sourceforge.net  Tue May  8 06:27:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 07 May 2001 22:27:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-422203 ] math.sqrt() broken on parisc-linux
Message-ID: <E14x02M-0007MR-00@usw-sf-web1.sourceforge.net>

Bugs item #422203, was updated on 2001-05-07 22:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422203&group_id=5470

>Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: dann frazier (dannf)
Assigned to: Nobody/Anonymous (nobody)
Summary: math.sqrt() broken on parisc-linux

Initial Comment:
python 2.0
Debian GNU/Linux on PA-RISC
package: python2-base_2.0-7

for any integer x, math.sqrt(x.0) seems to equal 0.0

----
sebadoh:/tmp# python2
Python 2.0 (#0, Apr 27 2001, 03:16:35) 
[GCC 3.0 20010315 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import math
>>> math.sqrt(2.0)
0.0
>>> math.sqrt(2)
1.4142135623730951
----

the C equivalent (math.h) reports the correct answer.

sebadoh:/tmp# uname -a
Linux sebadoh 2.4.0 #1 Mon May 7 12:41:27 MDT 2001
parisc unknown


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

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

Message:
Logged In: YES 
user_id=31435

Try recompiling with optimization off?  Python is written 
in C, and calls the same libm sqrt function you call when 
you write a C program.  It's very straightforward.  Nobody 
else has reported this problem, so there's something unique 
about your platform, and a buggy compiler is always the 
first guess when that occurs.

Also try a current version of Python (2.1 is current; 2.0 
is no longer supported officially, although a volunteer may 
produce a bugfix release for it).


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

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


From noreply@sourceforge.net  Tue May  8 08:34:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 00:34:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-422088 ] [OSF1 alpha] string.replace()
Message-ID: <E14x21B-0004Ia-00@usw-sf-web3.sourceforge.net>

Bugs item #422088, was updated on 2001-05-07 11:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422088&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Casado (martin_casado)
Assigned to: Nobody/Anonymous (nobody)
Summary: [OSF1 alpha] string.replace()

Initial Comment:
>>> import sys
>>> sys.version
'2.0c1 (#7, Jan 24 2001, 15:36:12) [C]'
>>> s = "123"
>>> s.replace("123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError
>>> os.uname()
('OSF1', 'xxx', 'V4.0', '1229', 'alpha')
>>> 


I haven't tried it with anything newer, perhaps this
bug
has already been posted and/or fixed, though I couldn't
find it in the buglist

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 00:34

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 19:58

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try recompiling with optimization 
turned off.  If that makes the problem go away (seems 
likely to me), it's a platform compiler bug.

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

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


From noreply@sourceforge.net  Tue May  8 09:06:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 01:06:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-422177 ] Results from .pyc differs from .py
Message-ID: <E14x2W2-0005HI-00@usw-sf-web2.sourceforge.net>

Bugs item #422177, was updated on 2001-05-07 18:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422177&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Results from .pyc differs from .py

Initial Comment:
Guido, the following is from c.l.py.  It *seems* to be 
due to marshal using damagingly low precision for 
float->string conversion.  If you don't object to my 
fixing it, assign this back to me.  But I'll still be 
baffled by why the .py result differs from the .pyc 
result (which I reproduced under current CVS, under 
Windows):


-----Original Message-----
From: python-list-admin@python.org
On Behalf Of Scott Ransom
Sent: Monday, May 07, 2001 4:27 PM
To: python-list@python.org
Cc: Scott Ransom
Subject: Variables different between .py and .pyc


Hello,

I'm running Python 2.0 on Linux and seem to have found
a strange problem when importing floating point
variables defined in modules.  I have not
tried this in Python 2.1 so I don't know if the
problem exists there as well.

Here is a simple module (vars.py):

PI    = 3.14159265358979324
TWOPI = 6.28318530717958648

When I import this and check the variable values here
is what I get:

presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535897931, 6.2831853071795862)

All is well, so far.  Now, if I try again (and this
time the interpreter loads from the newly created
vars.pyc file):

presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535900001, 6.2831853071800001)

My variables are truncated at ~12 decimal points of
precision.

Removing the .pyc file makes things "better" again...

presto:~$ rm vars.pyc
presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535897931, 6.2831853071795862)

...


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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-08 01:06

Message:
Logged In: YES 
user_id=31435

Quoting a msg of mine to c.l.py that may clarify things a 
bit:

[Aahz Maruch, on a proposed change to make .pyc/.pyo files
 store repr(float) instead of str(float)]

> Ouch.  This is the kind of situation where I was thinking
> that a distinction between "bugfix release"
> and "maintenance release" might be useful.  OTOH, it's
> hard to imagine a case where fixing this would make
> things worse....  I mean, really, what could this break?

Perhaps you have no experience with floating-point code 
<2/3 wink>?  Over the years I've spent a good (distributed) 
half year of my life tracking down gross problems in 
numerically naive algorithms triggered by measly 1-bit
differences.  This is a much bigger change than that.  Even 
a good algorithm will return *different* results, and of 
course some people will scream "different" == "broken".  
You can't fix *any* bug that changes a result without 
somebody feeling abused.

Trivial:

CONST = 0.0054794520547945206

i = int(CONST * 365)

The difference between current .pyc precision and 
proposed .pyc precision there is the difference between 
i==1 and i==2.  Can you imagine why changing an integer 
could break something?

Maybe this is more obvious (although it's really the same 
thing):

x = 9007199254740992.0
print long(x)

Stick that in a module and import it.  The first time you 
import it, it should print

9007199254740992

Which isn't surprising -- the number happens to be exactly 
2.**53.  Import it a second time and it will print 
something closer to

9007199254740000

If people have been getting bad numeric approximations out 
of their float literals in Python code for 10 years without 
knowing it, they've also been fiddling their algorithms to 
compensate for the "mysterious problems" they haven't 
tracked down.  Change what the literals denote, and the 
algorithmic compensations are suddenly wrong too.

It's a mess.

nevertheless-it's-clearly-broken-and-there's-only-one-
    way-to-fix-it-ly y'rs  - tim


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

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

Message:
Logged In: YES 
user_id=31435

I'm attaching a patch so people can try the fix x-
platform.  You need a current CVS Python (one with 
test/double_const.py) first.

If you apply *just* the test_import.py part of this patch, 
then I expect test_import to fail if and only if 
double_const.pyc exists.

After the whole patch, I expect test_import never to fail.  
But x-platform FP stuff is tricky, so I'd like a little x-
plat pre-testing before risking a checkin.  Works fine 
under Windows, of course. 

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

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


From noreply@sourceforge.net  Tue May  8 13:16:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 05:16:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-422265 ] Python 2.1 curses build failure on HPUX
Message-ID: <E14x6PQ-0007d2-00@usw-sf-web3.sourceforge.net>

Bugs item #422265, was updated on 2001-05-08 05:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422265&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 curses build failure on HPUX

Initial Comment:
Builing the curses module from Python 2.1 on HPUX 11.0 
fails with the following errors:

building '_curses' extension
cc -Ae -O +z -I. -I/home/richardt/python/Python-
2.1/./Include -I/usr/local/include -IInclude/ -
c /home/richardt/python/Python-
2.1/Modules/_cursesmodule.c -o build/temp.hp-ux-
B.11.00-9000/770-2.1/_cursesmodule.o
cc: line 309: warning 5004: Uninitialized 
variable "arg1" in function "PyCursesWindow_getbegyx" 
(5004)
cc: line 309: warning 5004: Uninitialized 
variable "arg2" in function "PyCursesWindow_getbegyx" 
(5004)
cc: line 310: warning 5004: Uninitialized 
variable "arg1" in function "PyCursesWindow_getmaxyx" 
(5004)
cc: line 310: warning 5004: Uninitialized 
variable "arg2" in function "PyCursesWindow_getmaxyx" 
(5004)
cc: line 311: warning 5004: Uninitialized 
variable "arg1" in function "PyCursesWindow_getparyx" 
(5004)
cc: line 311: warning 5004: Uninitialized 
variable "arg2" in function "PyCursesWindow_getparyx" 
(5004)

For full error listing see attached file curses.txt


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

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


From noreply@sourceforge.net  Tue May  8 13:33:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 05:33:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-422177 ] Results from .pyc differs from .py
Message-ID: <E14x6gN-0007sj-00@usw-sf-web3.sourceforge.net>

Bugs item #422177, was updated on 2001-05-07 18:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422177&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: Results from .pyc differs from .py

Initial Comment:
Guido, the following is from c.l.py.  It *seems* to be 
due to marshal using damagingly low precision for 
float->string conversion.  If you don't object to my 
fixing it, assign this back to me.  But I'll still be 
baffled by why the .py result differs from the .pyc 
result (which I reproduced under current CVS, under 
Windows):


-----Original Message-----
From: python-list-admin@python.org
On Behalf Of Scott Ransom
Sent: Monday, May 07, 2001 4:27 PM
To: python-list@python.org
Cc: Scott Ransom
Subject: Variables different between .py and .pyc


Hello,

I'm running Python 2.0 on Linux and seem to have found
a strange problem when importing floating point
variables defined in modules.  I have not
tried this in Python 2.1 so I don't know if the
problem exists there as well.

Here is a simple module (vars.py):

PI    = 3.14159265358979324
TWOPI = 6.28318530717958648

When I import this and check the variable values here
is what I get:

presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535897931, 6.2831853071795862)

All is well, so far.  Now, if I try again (and this
time the interpreter loads from the newly created
vars.pyc file):

presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535900001, 6.2831853071800001)

My variables are truncated at ~12 decimal points of
precision.

Removing the .pyc file makes things "better" again...

presto:~$ rm vars.pyc
presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535897931, 6.2831853071795862)

...


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-08 05:33

Message:
Logged In: YES 
user_id=6380

Works for me on Linux, so back to you, Tim.  I see no reason
why this could be platform-dependent, so check it in!

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-08 01:06

Message:
Logged In: YES 
user_id=31435

Quoting a msg of mine to c.l.py that may clarify things a 
bit:

[Aahz Maruch, on a proposed change to make .pyc/.pyo files
 store repr(float) instead of str(float)]

> Ouch.  This is the kind of situation where I was thinking
> that a distinction between "bugfix release"
> and "maintenance release" might be useful.  OTOH, it's
> hard to imagine a case where fixing this would make
> things worse....  I mean, really, what could this break?

Perhaps you have no experience with floating-point code 
<2/3 wink>?  Over the years I've spent a good (distributed) 
half year of my life tracking down gross problems in 
numerically naive algorithms triggered by measly 1-bit
differences.  This is a much bigger change than that.  Even 
a good algorithm will return *different* results, and of 
course some people will scream "different" == "broken".  
You can't fix *any* bug that changes a result without 
somebody feeling abused.

Trivial:

CONST = 0.0054794520547945206

i = int(CONST * 365)

The difference between current .pyc precision and 
proposed .pyc precision there is the difference between 
i==1 and i==2.  Can you imagine why changing an integer 
could break something?

Maybe this is more obvious (although it's really the same 
thing):

x = 9007199254740992.0
print long(x)

Stick that in a module and import it.  The first time you 
import it, it should print

9007199254740992

Which isn't surprising -- the number happens to be exactly 
2.**53.  Import it a second time and it will print 
something closer to

9007199254740000

If people have been getting bad numeric approximations out 
of their float literals in Python code for 10 years without 
knowing it, they've also been fiddling their algorithms to 
compensate for the "mysterious problems" they haven't 
tracked down.  Change what the literals denote, and the 
algorithmic compensations are suddenly wrong too.

It's a mess.

nevertheless-it's-clearly-broken-and-there's-only-one-
    way-to-fix-it-ly y'rs  - tim


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

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

Message:
Logged In: YES 
user_id=31435

I'm attaching a patch so people can try the fix x-
platform.  You need a current CVS Python (one with 
test/double_const.py) first.

If you apply *just* the test_import.py part of this patch, 
then I expect test_import to fail if and only if 
double_const.pyc exists.

After the whole patch, I expect test_import never to fail.  
But x-platform FP stuff is tricky, so I'd like a little x-
plat pre-testing before risking a checkin.  Works fine 
under Windows, of course. 

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

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


From noreply@sourceforge.net  Tue May  8 15:43:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 07:43:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-422320 ] 2.2a0 #include termio.h fails on FreeBSD
Message-ID: <E14x8iH-0001B0-00@usw-sf-web3.sourceforge.net>

Bugs item #422320, was updated on 2001-05-08 07:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422320&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.2a0 #include termio.h fails on FreeBSD

Initial Comment:
Recent change to termios module to #include termio.h
causes compilation to fail on FreeBSD where termio.h
does not exist. Other platforms may well be similar... 
termio.h seems to be a backward compatible type file -
does it really need to be included?

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

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


From noreply@sourceforge.net  Tue May  8 15:46:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 07:46:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-422320 ] 2.2a0 #include termio.h fails on FreeBSD
Message-ID: <E14x8l6-0001DF-00@usw-sf-web3.sourceforge.net>

Bugs item #422320, was updated on 2001-05-08 07:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422320&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Favas (mfavas)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 2.2a0 #include termio.h fails on FreeBSD

Initial Comment:
Recent change to termios module to #include termio.h
causes compilation to fail on FreeBSD where termio.h
does not exist. Other platforms may well be similar... 
termio.h seems to be a backward compatible type file -
does it really need to be included?

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

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


From noreply@sourceforge.net  Tue May  8 15:51:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 07:51:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-422088 ] [OSF1 alpha] string.replace()
Message-ID: <E14x8pp-0001JA-00@usw-sf-web3.sourceforge.net>

Bugs item #422088, was updated on 2001-05-07 11:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422088&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Casado (martin_casado)
Assigned to: Nobody/Anonymous (nobody)
Summary: [OSF1 alpha] string.replace()

Initial Comment:
>>> import sys
>>> sys.version
'2.0c1 (#7, Jan 24 2001, 15:36:12) [C]'
>>> s = "123"
>>> s.replace("123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError
>>> os.uname()
('OSF1', 'xxx', 'V4.0', '1229', 'alpha')
>>> 


I haven't tried it with anything newer, perhaps this
bug
has already been posted and/or fixed, though I couldn't
find it in the buglist

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 07:51

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 00:34

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 19:58

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try recompiling with optimization 
turned off.  If that makes the problem go away (seems 
likely to me), it's a platform compiler bug.

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

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


From noreply@sourceforge.net  Tue May  8 16:22:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 08:22:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-422177 ] Results from .pyc differs from .py
Message-ID: <E14x9Jb-0000CF-00@usw-sf-web1.sourceforge.net>

Bugs item #422177, was updated on 2001-05-07 18:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422177&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Results from .pyc differs from .py

Initial Comment:
Guido, the following is from c.l.py.  It *seems* to be 
due to marshal using damagingly low precision for 
float->string conversion.  If you don't object to my 
fixing it, assign this back to me.  But I'll still be 
baffled by why the .py result differs from the .pyc 
result (which I reproduced under current CVS, under 
Windows):


-----Original Message-----
From: python-list-admin@python.org
On Behalf Of Scott Ransom
Sent: Monday, May 07, 2001 4:27 PM
To: python-list@python.org
Cc: Scott Ransom
Subject: Variables different between .py and .pyc


Hello,

I'm running Python 2.0 on Linux and seem to have found
a strange problem when importing floating point
variables defined in modules.  I have not
tried this in Python 2.1 so I don't know if the
problem exists there as well.

Here is a simple module (vars.py):

PI    = 3.14159265358979324
TWOPI = 6.28318530717958648

When I import this and check the variable values here
is what I get:

presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535897931, 6.2831853071795862)

All is well, so far.  Now, if I try again (and this
time the interpreter loads from the newly created
vars.pyc file):

presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535900001, 6.2831853071800001)

My variables are truncated at ~12 decimal points of
precision.

Removing the .pyc file makes things "better" again...

presto:~$ rm vars.pyc
presto:~$ python
Python 2.0 (#6, Nov 16 2000, 12:32:08)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import vars
>>> vars.PI, vars.TWOPI
(3.1415926535897931, 6.2831853071795862)

...


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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-08 08:22

Message:
Logged In: YES 
user_id=31435

Checked in:

Lib/test/double_const.py; new file.
Lib/test/test_import.py; new revision: 1.4
Include/floatobject.h; new revision: 2.18
Objects/floatobject.c; new revision: 2.82
Python/marshal.c; new revision: 1.63


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-08 05:33

Message:
Logged In: YES 
user_id=6380

Works for me on Linux, so back to you, Tim.  I see no reason
why this could be platform-dependent, so check it in!

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-08 01:06

Message:
Logged In: YES 
user_id=31435

Quoting a msg of mine to c.l.py that may clarify things a 
bit:

[Aahz Maruch, on a proposed change to make .pyc/.pyo files
 store repr(float) instead of str(float)]

> Ouch.  This is the kind of situation where I was thinking
> that a distinction between "bugfix release"
> and "maintenance release" might be useful.  OTOH, it's
> hard to imagine a case where fixing this would make
> things worse....  I mean, really, what could this break?

Perhaps you have no experience with floating-point code 
<2/3 wink>?  Over the years I've spent a good (distributed) 
half year of my life tracking down gross problems in 
numerically naive algorithms triggered by measly 1-bit
differences.  This is a much bigger change than that.  Even 
a good algorithm will return *different* results, and of 
course some people will scream "different" == "broken".  
You can't fix *any* bug that changes a result without 
somebody feeling abused.

Trivial:

CONST = 0.0054794520547945206

i = int(CONST * 365)

The difference between current .pyc precision and 
proposed .pyc precision there is the difference between 
i==1 and i==2.  Can you imagine why changing an integer 
could break something?

Maybe this is more obvious (although it's really the same 
thing):

x = 9007199254740992.0
print long(x)

Stick that in a module and import it.  The first time you 
import it, it should print

9007199254740992

Which isn't surprising -- the number happens to be exactly 
2.**53.  Import it a second time and it will print 
something closer to

9007199254740000

If people have been getting bad numeric approximations out 
of their float literals in Python code for 10 years without 
knowing it, they've also been fiddling their algorithms to 
compensate for the "mysterious problems" they haven't 
tracked down.  Change what the literals denote, and the 
algorithmic compensations are suddenly wrong too.

It's a mess.

nevertheless-it's-clearly-broken-and-there's-only-one-
    way-to-fix-it-ly y'rs  - tim


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

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

Message:
Logged In: YES 
user_id=31435

I'm attaching a patch so people can try the fix x-
platform.  You need a current CVS Python (one with 
test/double_const.py) first.

If you apply *just* the test_import.py part of this patch, 
then I expect test_import to fail if and only if 
double_const.pyc exists.

After the whole patch, I expect test_import never to fail.  
But x-platform FP stuff is tricky, so I'd like a little x-
plat pre-testing before risking a checkin.  Works fine 
under Windows, of course. 

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

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


From noreply@sourceforge.net  Tue May  8 16:23:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 08:23:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-422339 ] 1 test failed: test_format
Message-ID: <E14x9Kv-0000Db-00@usw-sf-web1.sourceforge.net>

Bugs item #422339, was updated on 2001-05-08 08:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422339&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1 test failed: test_format 

Initial Comment:
Hallo!

OS:

OSF1 alpha04.faidor.de V4.0 1530 alpha

# cc -V
cc  (cc)
        Digital UNIX Compiler Driver 3.11
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)


Compiling and testing:

**********************************************************************
test_format
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == 
'00' != '0'", expected: ''


Version Python-2.1

Remark:

I found this error three times in the year 2000,
but resolved and for other Platforms

Kind regards
Hermann


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

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


From noreply@sourceforge.net  Tue May  8 22:26:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 14:26:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-422463 ] bug in Python 1.5.2 for win2k pro
Message-ID: <E14xF0B-0007gu-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pavel Khmelinsky (russhmepas)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in Python 1.5.2 for win2k pro

Initial Comment:
I think that I find bug in Python 1.5.2 for Win32
Hi! 

Ok, lets try this source code: 
------------------- 
def f(m): 
    for i in m: 
        print i 
  
m1 = range(5,10) 
f(m1) 
------------------ 

The output is: 
------------------ 
5 
6 
7 
8 
9 
------------------ 

All right, but lets try few differ source code: 
------------------ 
class cl: 
    def f(m): 
        for i in m: 
            print i 

c=cl() 
m1 = range(5,10) 
c.f(m1) 
----------------- 

And python interpretator returns me this error message: 
----------------- 
Traceback (innermost last): 
  File "test3.py", line 11, in ? 
     c.f(m1) 
TypeError: too many arguments; expected 1, got 2 
----------------- 

Not working! 
Why? I think that is it must working! 
I send just one argument to function. 
But is not working....  I think that this is bug, isn't it?
Please help me. May be you have solution of this problem. 

P.S.: Sorry for my English, my 1st language is Russian. 
P.P.S.: I am using W2k professional 

BG, 
Pavel Khmelinsky 
  

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

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


From noreply@sourceforge.net  Wed May  9 01:42:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 17:42:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-422463 ] bug in Python 1.5.2 for win2k pro
Message-ID: <E14xI3Y-0000V9-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Pavel Khmelinsky (russhmepas)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in Python 1.5.2 for win2k pro

Initial Comment:
I think that I find bug in Python 1.5.2 for Win32
Hi! 

Ok, lets try this source code: 
------------------- 
def f(m): 
    for i in m: 
        print i 
  
m1 = range(5,10) 
f(m1) 
------------------ 

The output is: 
------------------ 
5 
6 
7 
8 
9 
------------------ 

All right, but lets try few differ source code: 
------------------ 
class cl: 
    def f(m): 
        for i in m: 
            print i 

c=cl() 
m1 = range(5,10) 
c.f(m1) 
----------------- 

And python interpretator returns me this error message: 
----------------- 
Traceback (innermost last): 
  File "test3.py", line 11, in ? 
     c.f(m1) 
TypeError: too many arguments; expected 1, got 2 
----------------- 

Not working! 
Why? I think that is it must working! 
I send just one argument to function. 
But is not working....  I think that this is bug, isn't it?
Please help me. May be you have solution of this problem. 

P.S.: Sorry for my English, my 1st language is Russian. 
P.P.S.: I am using W2k professional 

BG, 
Pavel Khmelinsky 
  

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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-08 17:42

Message:
Logged In: YES 
user_id=31435

Not a bug.  Functions in the scope of a class stmt are 
methods of the class, and require an additional "self" 
argument, but a bug report isn't the place for a tutorial.  
Any book or tutorial on Python explains this in detail, 
though.  See http://www.python.org/ and click on the Help 
link near the top of the.


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

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


From noreply@sourceforge.net  Wed May  9 02:12:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 18:12:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-422339 ] 1 test failed: test_format
Message-ID: <E14xIWs-0001bY-00@usw-sf-web1.sourceforge.net>

Bugs item #422339, was updated on 2001-05-08 08:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422339&group_id=5470

>Category: Python Interpreter Core
Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1 test failed: test_format 

Initial Comment:
Hallo!

OS:

OSF1 alpha04.faidor.de V4.0 1530 alpha

# cc -V
cc  (cc)
        Digital UNIX Compiler Driver 3.11
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)


Compiling and testing:

**********************************************************************
test_format
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == 
'00' != '0'", expected: ''


Version Python-2.1

Remark:

I found this error three times in the year 2000,
but resolved and for other Platforms

Kind regards
Hermann


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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-08 18:12

Message:
Logged In: YES 
user_id=31435

The Compaq compiler is in violation of the C std if it 
produces "00" for printf("%#o", 0), and all Python does 
here under the covers is call the platform sprintf.

Sometimes we put ugly stuff inside Python to worm around 
platform C bugs, but in this case the Compaq compiler is 
the only known offender.  Not worth it.  If

printf("%#o", 0)

does produce two zeroes in a C program using this compiler, 
file a bug with them.  Does it?  I'm closing this as "won't 
fix" assuming it does.


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

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


From noreply@sourceforge.net  Wed May  9 04:27:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 20:27:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-420230 ] fileinput deletes backups without warnin
Message-ID: <E14xKdr-0002Tf-00@usw-sf-web3.sourceforge.net>

Bugs item #420230, was updated on 2001-04-30 12:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420230&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bernhard Reiter (ber)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: fileinput deletes backups without warnin

Initial Comment:
When using the fileinput module with inplace=1 and a
specific
backup extension the file stays around as documented,
but if it existed before it gets overwritten without
warning.
This should be documented. 

"Backup files are overriden silently."

Other possible fixes could include adding an
overwrite=0 argument
so that an exceptions is thrown when overwrite=0.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-08 20:27

Message:
Logged In: YES 
user_id=3066

Documentation corrected in Doc/lib/libfileinput.tex
revisions 1.6 (development trunk) and 1.5.8.1 (2.1
maintenance branch).

Specific annotation added:

"(if a file of the same name as the backup file already
exists, it will be replaced silently)"

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

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


From noreply@sourceforge.net  Wed May  9 05:05:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 08 May 2001 21:05:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-420216 ] bad links in v2.1 docs
Message-ID: <E14xLEM-0002sz-00@usw-sf-web3.sourceforge.net>

Bugs item #420216, was updated on 2001-04-30 11:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420216&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bad links in v2.1 docs

Initial Comment:
The file 'module-imap.html' is linked, but not 
supplied (see grep at bottom).

Also, there are several links to "about.html" in 
the "doc\dist" directory.  However, no "about.html" is 
supplied there.

Thanks!

=g2

----------------
F:\apps\Python21\Doc>grep -d+ module-imap.html *.html
File lib\module-poplib.html:
using the <tt class='module'><a href='module-
IMAP.html'>IMAP</a></tt> class, as
IMAP servers tend to be better
File lib\pop3-objects.html:
    <dt>Module <b><tt class='module'><a href='module-
imap.html'>imap</a></tt>:</
b>

F:\apps\Python21\Doc>dir module-imap.html /s
 Volume in drive F has no label.
 Volume Serial Number is 

File Not Found

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-08 21:05

Message:
Logged In: YES 
user_id=3066

The poplib documentation error is corrected in
Doc/lib/libpoplib.tex revision 1.12 (development branch) and
revision 1.11.4.1 (2.1 maintenance branch).

The "About..." page error is corrected by an update to the
Doc/tools/mkhowto script -- revisions 1.25 and 1.24.4.1.

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

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


From noreply@sourceforge.net  Wed May  9 09:10:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 01:10:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-422339 ] 1 test failed: test_format
Message-ID: <E14xP2r-00081w-00@usw-sf-web1.sourceforge.net>

Bugs item #422339, was updated on 2001-05-08 08:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422339&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1 test failed: test_format 

Initial Comment:
Hallo!

OS:

OSF1 alpha04.faidor.de V4.0 1530 alpha

# cc -V
cc  (cc)
        Digital UNIX Compiler Driver 3.11
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)


Compiling and testing:

**********************************************************************
test_format
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == 
'00' != '0'", expected: ''


Version Python-2.1

Remark:

I found this error three times in the year 2000,
but resolved and for other Platforms

Kind regards
Hermann


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:10

Message:
Logged In: NO 

Hermann.Rochholz@gmx.de

Hello!

But why doesn't python use the gcc?
It's installed and every program I've translated before 
uses it automatiocally.

Regards
Hermann



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

Comment By: Tim Peters (tim_one)
Date: 2001-05-08 18:12

Message:
Logged In: YES 
user_id=31435

The Compaq compiler is in violation of the C std if it 
produces "00" for printf("%#o", 0), and all Python does 
here under the covers is call the platform sprintf.

Sometimes we put ugly stuff inside Python to worm around 
platform C bugs, but in this case the Compaq compiler is 
the only known offender.  Not worth it.  If

printf("%#o", 0)

does produce two zeroes in a C program using this compiler, 
file a bug with them.  Does it?  I'm closing this as "won't 
fix" assuming it does.


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

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


From noreply@sourceforge.net  Wed May  9 09:29:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 01:29:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-422339 ] 1 test failed: test_format
Message-ID: <E14xPLN-0005qZ-00@usw-sf-web3.sourceforge.net>

Bugs item #422339, was updated on 2001-05-08 08:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422339&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1 test failed: test_format 

Initial Comment:
Hallo!

OS:

OSF1 alpha04.faidor.de V4.0 1530 alpha

# cc -V
cc  (cc)
        Digital UNIX Compiler Driver 3.11
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)


Compiling and testing:

**********************************************************************
test_format
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == 
'00' != '0'", expected: ''


Version Python-2.1

Remark:

I found this error three times in the year 2000,
but resolved and for other Platforms

Kind regards
Hermann


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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-09 01:29

Message:
Logged In: YES 
user_id=31435

Sorry, I see nothing surprising about Python using whatever 
cc resolves to by default on the system.  If you don't want 
C programs to use cc, change cc.

If you want it to use gcc on this platform instead, you 
should open a different bug report, or, better, supply a 
patch to the Unix config process:  the chance that any 
active Python developer uses this particular plaform is 
approximately 0, so that's also the chance that anyone can 
write and test a config change for you.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:10

Message:
Logged In: NO 

Hermann.Rochholz@gmx.de

Hello!

But why doesn't python use the gcc?
It's installed and every program I've translated before 
uses it automatiocally.

Regards
Hermann



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

Comment By: Tim Peters (tim_one)
Date: 2001-05-08 18:12

Message:
Logged In: YES 
user_id=31435

The Compaq compiler is in violation of the C std if it 
produces "00" for printf("%#o", 0), and all Python does 
here under the covers is call the platform sprintf.

Sometimes we put ugly stuff inside Python to worm around 
platform C bugs, but in this case the Compaq compiler is 
the only known offender.  Not worth it.  If

printf("%#o", 0)

does produce two zeroes in a C program using this compiler, 
file a bug with them.  Does it?  I'm closing this as "won't 
fix" assuming it does.


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

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


From noreply@sourceforge.net  Wed May  9 09:30:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 01:30:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-422339 ] 1 test failed: test_format
Message-ID: <E14xPMd-00077u-00@usw-sf-web2.sourceforge.net>

Bugs item #422339, was updated on 2001-05-08 08:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422339&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1 test failed: test_format 

Initial Comment:
Hallo!

OS:

OSF1 alpha04.faidor.de V4.0 1530 alpha

# cc -V
cc  (cc)
        Digital UNIX Compiler Driver 3.11
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)


Compiling and testing:

**********************************************************************
test_format
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == 
'00' != '0'", expected: ''


Version Python-2.1

Remark:

I found this error three times in the year 2000,
but resolved and for other Platforms

Kind regards
Hermann


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:30

Message:
Logged In: NO 

Hello!

Now I tried with gcc 
and the same error appears. Why?

./configure --prefix=/opt_prog/local --with-gcc
gmake 
gmake test
-------
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == '00' != 
'0'", expected: ''
--------


and the whole thing is compiled with gcc.(2.95.3)

Hermann


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 01:29

Message:
Logged In: YES 
user_id=31435

Sorry, I see nothing surprising about Python using whatever 
cc resolves to by default on the system.  If you don't want 
C programs to use cc, change cc.

If you want it to use gcc on this platform instead, you 
should open a different bug report, or, better, supply a 
patch to the Unix config process:  the chance that any 
active Python developer uses this particular plaform is 
approximately 0, so that's also the chance that anyone can 
write and test a config change for you.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:10

Message:
Logged In: NO 

Hermann.Rochholz@gmx.de

Hello!

But why doesn't python use the gcc?
It's installed and every program I've translated before 
uses it automatiocally.

Regards
Hermann



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

Comment By: Tim Peters (tim_one)
Date: 2001-05-08 18:12

Message:
Logged In: YES 
user_id=31435

The Compaq compiler is in violation of the C std if it 
produces "00" for printf("%#o", 0), and all Python does 
here under the covers is call the platform sprintf.

Sometimes we put ugly stuff inside Python to worm around 
platform C bugs, but in this case the Compaq compiler is 
the only known offender.  Not worth it.  If

printf("%#o", 0)

does produce two zeroes in a C program using this compiler, 
file a bug with them.  Does it?  I'm closing this as "won't 
fix" assuming it does.


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

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


From noreply@sourceforge.net  Wed May  9 09:46:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 01:46:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-422339 ] 1 test failed: test_format
Message-ID: <E14xPcH-00064k-00@usw-sf-web3.sourceforge.net>

Bugs item #422339, was updated on 2001-05-08 08:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422339&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1 test failed: test_format 

Initial Comment:
Hallo!

OS:

OSF1 alpha04.faidor.de V4.0 1530 alpha

# cc -V
cc  (cc)
        Digital UNIX Compiler Driver 3.11
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)


Compiling and testing:

**********************************************************************
test_format
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == 
'00' != '0'", expected: ''


Version Python-2.1

Remark:

I found this error three times in the year 2000,
but resolved and for other Platforms

Kind regards
Hermann


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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-09 01:46

Message:
Logged In: YES 
user_id=31435

I don't have access to this platform, so can't tell you.  
Did you try running the little C program I mentioned?

#include <stdio.h>
void main() {
printf("%#o\n", 0);
}

Does that print "0" or "00"?  If it prints "00", there's 
little we can do about it.  If it prints "0", we may have a 
problem (or may not; e.g., if you didn't start over from 
scratch, it's possible that you're picking up the old 
executable by mistake).

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:30

Message:
Logged In: NO 

Hello!

Now I tried with gcc 
and the same error appears. Why?

./configure --prefix=/opt_prog/local --with-gcc
gmake 
gmake test
-------
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == '00' != 
'0'", expected: ''
--------


and the whole thing is compiled with gcc.(2.95.3)

Hermann


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 01:29

Message:
Logged In: YES 
user_id=31435

Sorry, I see nothing surprising about Python using whatever 
cc resolves to by default on the system.  If you don't want 
C programs to use cc, change cc.

If you want it to use gcc on this platform instead, you 
should open a different bug report, or, better, supply a 
patch to the Unix config process:  the chance that any 
active Python developer uses this particular plaform is 
approximately 0, so that's also the chance that anyone can 
write and test a config change for you.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:10

Message:
Logged In: NO 

Hermann.Rochholz@gmx.de

Hello!

But why doesn't python use the gcc?
It's installed and every program I've translated before 
uses it automatiocally.

Regards
Hermann



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

Comment By: Tim Peters (tim_one)
Date: 2001-05-08 18:12

Message:
Logged In: YES 
user_id=31435

The Compaq compiler is in violation of the C std if it 
produces "00" for printf("%#o", 0), and all Python does 
here under the covers is call the platform sprintf.

Sometimes we put ugly stuff inside Python to worm around 
platform C bugs, but in this case the Compaq compiler is 
the only known offender.  Not worth it.  If

printf("%#o", 0)

does produce two zeroes in a C program using this compiler, 
file a bug with them.  Does it?  I'm closing this as "won't 
fix" assuming it does.


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

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


From noreply@sourceforge.net  Wed May  9 09:59:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 01:59:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-422339 ] 1 test failed: test_format
Message-ID: <E14xPoJ-0000LT-00@usw-sf-web1.sourceforge.net>

Bugs item #422339, was updated on 2001-05-08 08:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422339&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1 test failed: test_format 

Initial Comment:
Hallo!

OS:

OSF1 alpha04.faidor.de V4.0 1530 alpha

# cc -V
cc  (cc)
        Digital UNIX Compiler Driver 3.11
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)


Compiling and testing:

**********************************************************************
test_format
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == 
'00' != '0'", expected: ''


Version Python-2.1

Remark:

I found this error three times in the year 2000,
but resolved and for other Platforms

Kind regards
Hermann


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:59

Message:
Logged In: NO 

Hallo!

Sorry, I program Fortran and IDL, 
but I am not familiar with C.
But I can run it:

In both cases 
cc test.c
gcc test.c 

it prints out 
"00"
 
(gcc test.c
test.c: In function `main':
test.c:3: warning: return type of `main' is not `int')

Hermann



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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 01:46

Message:
Logged In: YES 
user_id=31435

I don't have access to this platform, so can't tell you.  
Did you try running the little C program I mentioned?

#include <stdio.h>
void main() {
printf("%#o\n", 0);
}

Does that print "0" or "00"?  If it prints "00", there's 
little we can do about it.  If it prints "0", we may have a 
problem (or may not; e.g., if you didn't start over from 
scratch, it's possible that you're picking up the old 
executable by mistake).

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:30

Message:
Logged In: NO 

Hello!

Now I tried with gcc 
and the same error appears. Why?

./configure --prefix=/opt_prog/local --with-gcc
gmake 
gmake test
-------
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == '00' != 
'0'", expected: ''
--------


and the whole thing is compiled with gcc.(2.95.3)

Hermann


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 01:29

Message:
Logged In: YES 
user_id=31435

Sorry, I see nothing surprising about Python using whatever 
cc resolves to by default on the system.  If you don't want 
C programs to use cc, change cc.

If you want it to use gcc on this platform instead, you 
should open a different bug report, or, better, supply a 
patch to the Unix config process:  the chance that any 
active Python developer uses this particular plaform is 
approximately 0, so that's also the chance that anyone can 
write and test a config change for you.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:10

Message:
Logged In: NO 

Hermann.Rochholz@gmx.de

Hello!

But why doesn't python use the gcc?
It's installed and every program I've translated before 
uses it automatiocally.

Regards
Hermann



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

Comment By: Tim Peters (tim_one)
Date: 2001-05-08 18:12

Message:
Logged In: YES 
user_id=31435

The Compaq compiler is in violation of the C std if it 
produces "00" for printf("%#o", 0), and all Python does 
here under the covers is call the platform sprintf.

Sometimes we put ugly stuff inside Python to worm around 
platform C bugs, but in this case the Compaq compiler is 
the only known offender.  Not worth it.  If

printf("%#o", 0)

does produce two zeroes in a C program using this compiler, 
file a bug with them.  Does it?  I'm closing this as "won't 
fix" assuming it does.


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

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


From noreply@sourceforge.net  Wed May  9 10:17:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 02:17:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-422339 ] 1 test failed: test_format
Message-ID: <E14xQ6T-0000fb-00@usw-sf-web1.sourceforge.net>

Bugs item #422339, was updated on 2001-05-08 08:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422339&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
>Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 1 test failed: test_format 

Initial Comment:
Hallo!

OS:

OSF1 alpha04.faidor.de V4.0 1530 alpha

# cc -V
cc  (cc)
        Digital UNIX Compiler Driver 3.11
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)


Compiling and testing:

**********************************************************************
test_format
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == 
'00' != '0'", expected: ''


Version Python-2.1

Remark:

I found this error three times in the year 2000,
but resolved and for other Platforms

Kind regards
Hermann


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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-09 02:17

Message:
Logged In: YES 
user_id=31435

Hermann, for someone who doesn't use C, you're doing great!

Alas, I don't use gcc, so I'm at a dead end.  I've assigned 
the bug to Fred Drake and reopened it.  It's 5am where I 
live and I need to go to sleep.  Fred will be up in a few 
hours, and I hope he can take a look at this then.  Python 
runs and passes this test on *many* platforms that use gcc, 
so there's still something very odd here.  Fred, have a 
guess?  I tried it under Cygwin gcc, and the little C 
program prints "0" as expected (gcc version 2.95.3-4) -- 
but glibc is more relevant.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:59

Message:
Logged In: NO 

Hallo!

Sorry, I program Fortran and IDL, 
but I am not familiar with C.
But I can run it:

In both cases 
cc test.c
gcc test.c 

it prints out 
"00"
 
(gcc test.c
test.c: In function `main':
test.c:3: warning: return type of `main' is not `int')

Hermann



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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 01:46

Message:
Logged In: YES 
user_id=31435

I don't have access to this platform, so can't tell you.  
Did you try running the little C program I mentioned?

#include <stdio.h>
void main() {
printf("%#o\n", 0);
}

Does that print "0" or "00"?  If it prints "00", there's 
little we can do about it.  If it prints "0", we may have a 
problem (or may not; e.g., if you didn't start over from 
scratch, it's possible that you're picking up the old 
executable by mistake).

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:30

Message:
Logged In: NO 

Hello!

Now I tried with gcc 
and the same error appears. Why?

./configure --prefix=/opt_prog/local --with-gcc
gmake 
gmake test
-------
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == '00' != 
'0'", expected: ''
--------


and the whole thing is compiled with gcc.(2.95.3)

Hermann


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 01:29

Message:
Logged In: YES 
user_id=31435

Sorry, I see nothing surprising about Python using whatever 
cc resolves to by default on the system.  If you don't want 
C programs to use cc, change cc.

If you want it to use gcc on this platform instead, you 
should open a different bug report, or, better, supply a 
patch to the Unix config process:  the chance that any 
active Python developer uses this particular plaform is 
approximately 0, so that's also the chance that anyone can 
write and test a config change for you.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:10

Message:
Logged In: NO 

Hermann.Rochholz@gmx.de

Hello!

But why doesn't python use the gcc?
It's installed and every program I've translated before 
uses it automatiocally.

Regards
Hermann



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

Comment By: Tim Peters (tim_one)
Date: 2001-05-08 18:12

Message:
Logged In: YES 
user_id=31435

The Compaq compiler is in violation of the C std if it 
produces "00" for printf("%#o", 0), and all Python does 
here under the covers is call the platform sprintf.

Sometimes we put ugly stuff inside Python to worm around 
platform C bugs, but in this case the Compaq compiler is 
the only known offender.  Not worth it.  If

printf("%#o", 0)

does produce two zeroes in a C program using this compiler, 
file a bug with them.  Does it?  I'm closing this as "won't 
fix" assuming it does.


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

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


From noreply@sourceforge.net  Wed May  9 16:17:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 08:17:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-422669 ] Bug with appending objects to list.
Message-ID: <E14xVit-0002Yd-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pavel Khmelinsky (russhmepas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug with appending objects to list.

Initial Comment:
Please, excuse me if this problem is problem of my brain and not a bug....

1st source:
*******************
>>> class cl:
... 	i = 0
...	def grown(self):
...		self.i = self.i + 1
...
...c = cl()
...db = []
...j = 0
...for i in range(0, 10):
...	c.grown()
...	db.append(c)
...	print vars( db[j] )
...	j = j + 1
{'i': 1}
{'i': 2}
{'i': 3}
{'i': 4}
{'i': 5}
{'i': 6}
{'i': 7}
{'i': 8}
{'i': 9}
{'i': 10}
*****************

All rights!

Lets try to see whats the members of the list "db" after end of cycle:

*****************
>>> class cl:
... 	i = 0
... 	def grown(self):
... 		self.i = self.i + 1
... 
... c = cl()
... db = []
... for i in range(0, 10):
... 	c.grown()
... 	db.append(c)
... 
... for j in db:
... 	print vars(j)
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
********************

Why!? Why all members of list are similiar?
This problem doesn'n exist if I appending to list a sipmle type variable (like integer), not
a class object.

P.S.: Sorry for my English, my 1st language is Russian. 
P.P.S.: I am using W2k professional 

Regards,
Pavel Khmelinsky

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

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


From noreply@sourceforge.net  Wed May  9 16:37:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 08:37:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-422669 ] Bug with appending objects to list.
Message-ID: <E14xW1S-0006yb-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Pavel Khmelinsky (russhmepas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug with appending objects to list.

Initial Comment:
Please, excuse me if this problem is problem of my brain and not a bug....

1st source:
*******************
>>> class cl:
... 	i = 0
...	def grown(self):
...		self.i = self.i + 1
...
...c = cl()
...db = []
...j = 0
...for i in range(0, 10):
...	c.grown()
...	db.append(c)
...	print vars( db[j] )
...	j = j + 1
{'i': 1}
{'i': 2}
{'i': 3}
{'i': 4}
{'i': 5}
{'i': 6}
{'i': 7}
{'i': 8}
{'i': 9}
{'i': 10}
*****************

All rights!

Lets try to see whats the members of the list "db" after end of cycle:

*****************
>>> class cl:
... 	i = 0
... 	def grown(self):
... 		self.i = self.i + 1
... 
... c = cl()
... db = []
... for i in range(0, 10):
... 	c.grown()
... 	db.append(c)
... 
... for j in db:
... 	print vars(j)
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
********************

Why!? Why all members of list are similiar?
This problem doesn'n exist if I appending to list a sipmle type variable (like integer), not
a class object.

P.S.: Sorry for my English, my 1st language is Russian. 
P.P.S.: I am using W2k professional 

Regards,
Pavel Khmelinsky

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

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

Message:
Logged In: YES 
user_id=31392

In the second example, you've append the *same object* to
the list
each time. 


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

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


From noreply@sourceforge.net  Wed May  9 16:50:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 08:50:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-420724 ] urllib2 and non existing local files
Message-ID: <E14xWDw-0004NB-00@usw-sf-web2.sourceforge.net>

Bugs item #420724, was updated on 2001-05-02 07:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420724&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 and non existing local files

Initial Comment:
When trying to open local files
with urllib2 in Python 2.1 urllib2 raises
an AssertionError instead of an IOError:

>>> import urllib2
>>> f = urllib2.urlopen("I don't exist")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/urllib2.py", line 
135, in urlopen
    return _opener.open(url, data)
  File "/usr/local/lib/python2.1/urllib2.py", line 
316, in open
    type_ = req.get_type()
  File "/usr/local/lib/python2.1/urllib2.py", line 
220, in get_type
    assert self.type is not None, self.__original
AssertionError: I don't exist


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

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

Message:
Logged In: YES 
user_id=31392

urllib2 doesn't allow you to open local files with just a
bare path.
you need to say file://

The error message isn't helpful, though.  Rev 1.14 of
urllib2.py will raise a ValueError with an explanation of
what went wrong.


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

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


From noreply@sourceforge.net  Wed May  9 16:50:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 08:50:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-422678 ] argv is modified in Py_Main()
Message-ID: <E14xWEn-0004OC-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: argv is modified in Py_Main()

Initial Comment:
Context: Python 2.1 release

In function Py_Main( argc, argv), @[file main.c, line 287], argv is modified: 		
'argv[_PyOS_optind] = "-c";'

argv[] should remain constant, and should not be modified; I am getting a coredump when cleaning 
up the contents of argv[] in the calling process...

If you feel you need to modify argv[]; a copy of the array should be made at the beginning of 
Py_Main(), and then work/modify the copy; not the original !!!

Meanwhile, I'll pass a copy of argv to Py_Main(), and will clean up the original!!

FG


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

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


From noreply@sourceforge.net  Wed May  9 16:53:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 08:53:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-420399 ] wrong HTML ("trademark" symbols?)
Message-ID: <E14xWHN-000334-00@usw-sf-web3.sourceforge.net>

Bugs item #420399, was updated on 2001-05-01 01:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420399&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: wrong HTML ("trademark" symbols?)

Initial Comment:
In the files:
http://python.sourceforge.net/maint-docs/lib/allos.html
http://python.sourceforge.net/maint-docs/lib/unix.html
http://python.sourceforge.net/maint-docs/lib/misc.html
http://python.sourceforge.net/maint-
docs/lib/netdata.html

there are wrong HTML codes, right after the 
words "ASCII", "POSIX" and/or "Unix".
Maybe they correspond to trademark symbols?

I am browsing those files either with MSIE 5.5 or 
Netscape 6.0 on a Win2K machine.

[I seem to remember that this was reported before, but 
I couldn't find on sourceforge. Was it by mail?]

-Hernán


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

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

Message:
Logged In: YES 
user_id=3066

The weird data that got tossed out was from LaTeX2HTML's
internal data munging.  Worked around by modifying the
markup in several of the document source files.  Fix checked
into both the development branch and 2.1 maintenance branch.

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

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


From noreply@sourceforge.net  Wed May  9 16:53:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 08:53:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-420720 ] Starting many threads causes core dump
Message-ID: <E14xWHj-0004QO-00@usw-sf-web2.sourceforge.net>

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

Category: Threads
Group: None
Status: Open
Resolution: None
>Priority: 4
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Starting many threads causes core dump

Initial Comment:
If I start more than 1020 threads simultaneously, using
the threading module, Python 2.1 causes segmentation
faults, or will not exit, under Linux. I have not
tested this on Windows.

I don't know whether the problems are caused by the
threads themselves, or the threading.Event for which
they are waiting.

I have attached a program threadKill3.py which
demonstrates this (including sample runs and output).


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

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

Message:
Logged In: YES 
user_id=31392

We need two things in order to offer any useful help:
1. A stack trace from the core file.
2. Evidence that a C program that starts 1024 threads
   won't do the same thing.


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

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


From noreply@sourceforge.net  Wed May  9 16:55:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 08:55:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-419462 ] python 2.0 compile fails on mandrake 8
Message-ID: <E14xWJf-0004SG-00@usw-sf-web2.sourceforge.net>

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

>Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Luke Kenneth Casson Leighton (lkcl)
>Assigned to: A.M. Kuchling (akuchling)
Summary: python 2.0 compile fails on mandrake 8

Initial Comment:
bddbmodule fails to compile on mandrake 8.

if bdb is not a mandatory module, autoconf should be
used to
detect that bdb is or is not installed.  [it's looking
for
R_NEXT etc. which don't exist]

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

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

Message:
Logged In: YES 
user_id=31392

I wonder if the builtin bsddb module should be deprecated. 
The fact
that it gets built causes a fair bit of trouble for users of
bsddb3,
which I assume is the preferred interface.


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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-04 04:12

Message:
Logged In: YES 
user_id=80200

update: there is an option in the Modules setup which can be
used to explicity disable bddb.  however, this, i feel,
should be totally unnecessary.

why exactly, is autoconf used, when it cannot be told -
correctly -
not to use bddb?  i attempted a compile with --without-bddb
(or
whatever it was), and it still failed.  because there just
_happens_
to be a db.h file _somewhere_ on the system, the configure
test "assumes" that there is a valid bddb somewhere, which
there isn't.

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

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


From noreply@sourceforge.net  Wed May  9 16:56:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 08:56:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-419390 ] base64.py could be smarter...
Message-ID: <E14xWJu-0004Sv-00@usw-sf-web2.sourceforge.net>

Bugs item #419390, was updated on 2001-04-26 23:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419390&group_id=5470

Category: Python Library
>Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: base64.py could be smarter...

Initial Comment:
base64.encodestring and decodestring take the
provided string, wrap it in a StringIO, then 
pass it to encode/decode which uses read() to 
pull it back out again. 

Seems pretty inefficient.

Replacing decodestring with:
  return binascii.a2b_base64(s)

results in a speedup of a factor of 16 or so.
(my sample: a 2Mb encoded voice message - takes
an average of 10s in the current form, and 0.6s
using just binascii.)

A similar speedup for encodestring seems possible.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-07 21:27

Message:
Logged In: YES 
user_id=31392

Anthony,
Could you submit a patch?


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

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


From noreply@sourceforge.net  Wed May  9 16:57:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 08:57:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-420725 ] urllib: MIME header for local files
Message-ID: <E14xWKj-0004TW-00@usw-sf-web2.sourceforge.net>

Bugs item #420725, was updated on 2001-05-02 07:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420725&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: Paul Prescod (prescod)
Summary: urllib: MIME header for local files

Initial Comment:
For local files urllib.py doesn't return the MIME 
headers that the documentation says it does:

http://www.python.org/doc/current/lib/module-
urllib.html#l2h-2187 states that "When the method is 
local-file, returned headers will include a Date 
representing the file's last-modified time, a Content-
Length giving file size, and a Content-Type containing 
a guess at the file's type"

But in Python 2.1 the only header that gets returned
is the Content-Type:

>>> import urllib
>>> f = urllib.urlopen("gurk.txt")      
>>> f.info().headers  
['Content-Type: text/plain\n']


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

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

Message:
Logged In: YES 
user_id=31392

What do you think, Paul?


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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-05-02 09:22

Message:
Logged In: YES 
user_id=89016

A patch (#420753) has been upload to SF.

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

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


From noreply@sourceforge.net  Wed May  9 16:57:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 08:57:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-417290 ] [Solaris] errors in _curses extension
Message-ID: <E14xWLX-0004U4-00@usw-sf-web2.sourceforge.net>

Bugs item #417290, was updated on 2001-04-19 01:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417290&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dimitri Papadopoulos (papadopo)
>Assigned to: Eric S. Raymond (esr)
Summary: [Solaris] errors in _curses extension

Initial Comment:
Hi,

Building with the Sun compiler on Solaris 7:

$ make all
[...]
building '_curses' extension
cc -I. -I/tmp/Python-2.1/./Include -I/usr/local/include
-IInclude/ -c /tmp/Python-2.1/Modules/_cursesmodule.c
-o build/temp.solaris-2.7-sun4u-2.1/_cursesmodule.o -O
-I. -I./Include -DHAVE_CONFIG_H
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
undefined symbol: attr_t
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
syntax error before or at: arg1
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 313:
undefined symbol: arg1
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 314:
undefined symbol: attr_t
"/tmp/Python-2.1/Modules/_cursesmodule.c", line 314:
syntax error before or at: arg1
[...]
$

Solaris 7 has only <curses.h> not <ncurses.h> and
attr_t seems to be specific to <ncurses.h>.

Regards,
Dimitri



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

Comment By: Dimitri Papadopoulos (papadopo)
Date: 2001-04-19 01:59

Message:
Logged In: YES 
user_id=52414

This is with Python 2.1 by the way.


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

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


From noreply@sourceforge.net  Wed May  9 16:58:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 08:58:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-417240 ] [Solaris] warning during build
Message-ID: <E14xWLi-0004US-00@usw-sf-web2.sourceforge.net>

Bugs item #417240, was updated on 2001-04-19 00:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417240&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dimitri Papadopoulos (papadopo)
>Assigned to: Eric S. Raymond (esr)
Summary: [Solaris] warning during build

Initial Comment:
Hi,

While building on Solaris with Sun's compiler I get
this warning:

$ ./configure --prefix=/usr/local/python-2.1
--with-signal-module --with-threads
$make all
[...]
building '_curses_panel' extension
cc -I. -I/tmp/Python-2.1/./Include -I/usr/local/include
-IInclude/ -c /tmp/Python-2.1/Modules/_curses_panel.c
-o build/temp.solaris-2.7-sun4u-2.1/_curses_panel.o -O
-I. -I./Include -DHAVE_CONFIG_H
"/tmp/Python-2.1/Modules/_curses_panel.c", line 307:
warning: argument #2 is incompatible with prototype:
        prototype: pointer to char :
"/usr/include/panel.h", line 51
        argument : pointer to struct _object {int
ob_refcnt, pointer to struct _typeobject {..} ob_type}
[...]

This is only a warning, not very important.

Best Regards,
Dimitri


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

Comment By: Dimitri Papadopoulos (papadopo)
Date: 2001-04-19 02:01

Message:
Logged In: YES 
user_id=52414

This is with Python 2.1 by the way.


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

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


From noreply@sourceforge.net  Wed May  9 17:00:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:00:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-417913 ] odd behavior when reloading "exceptions"
Message-ID: <E14xWNn-0004Wc-00@usw-sf-web2.sourceforge.net>

Bugs item #417913, was updated on 2001-04-21 14:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417913&group_id=5470

>Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Klatt (michaelklatt)
>Assigned to: Guido van Rossum (gvanrossum)
>Summary: odd behavior when reloading "exceptions"

Initial Comment:

After reloading the "exceptions" module, "exceptions.OSError" is not the same object as "os.error".

Let me illustrate by example:


# ./python
Python 2.1 (#1, Apr 20 2001, 23:16:45) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os, exceptions
>>> os.error == exceptions.OSError
1
>>> reload(exceptions)
<module 'exceptions' (built-in)>
>>> os.error == exceptions.OSError
0
>>>


Here's an example of how this could wreak havoc in a python script:

# ./python
Python 2.1 (#1, Apr 20 2001, 23:16:45) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> import exceptions
>>> 
>>> try:
...    os.stat("dummy")
... except os.error, e:
...     print "exception caught"
... 
exception caught
>>> reload(exceptions)
<module 'exceptions' (built-in)>
>>> 
>>> try:
...    os.stat("dummy")
... except os.error, e:
...     print "exception caught"
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in ?
OSError: [Errno 2] No such file or directory: 'dummy'
>>> 


A quick test shows that this problem also occurred in python 1.5.2 and python 2.0.  I believe I 
understand why this is happening (when the exceptions module is reloaded, a new object for 
OSError is created), but I'm hoping someone has a creative solution.  

This will cause problems in any application which calls Py_NewInterpreter() (like mod_python).  
To verify this, add the following lines to Demo/embed/demo.c at line 36:

 
        PyRun_SimpleString("import os,exceptions\n");
        PyRun_SimpleString("print os.error == exceptions.OSError\n");
 
        Py_NewInterpreter(); 
        PyRun_SimpleString("import os,exceptions\n");
        PyRun_SimpleString("print os.error == exceptions.OSError\n");

The first comparison will result in 1, and the second will result in 0. 

Thanks!

Mike



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

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

Message:
Logged In: YES 
user_id=31392

It seems like a bug, except that it also seems obviously
correct <wink>.  Any opinion about whether we should fix
this?


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

Comment By: Michael Klatt (michaelklatt)
Date: 2001-04-21 23:44

Message:
Logged In: YES 
user_id=201661


I did find a workaround for mod_python (and any application that uses Py_NewInterpreter()...).  I modified it 
to add this line after *every* call to Py_NewInterpreter()

PyRun_SimpleString("__import__(\os\).error = __import__(\exceptions\).OSError\n");

This is ugly, but it's a works.

Mike


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

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


From noreply@sourceforge.net  Wed May  9 17:00:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:00:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-422004 ] Missing "fixup" for "exceptions" module
Message-ID: <E14xWOD-0004Wn-00@usw-sf-web2.sourceforge.net>

Bugs item #422004, was updated on 2001-05-07 05:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422004&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jürgen Hermann (jhermann)
>Assigned to: Guido van Rossum (gvanrossum)
>Summary: Missing "fixup" for "exceptions" module

Initial Comment:
The following call is missing in Py_Initialize():

*** pythonrun.c,1       Mon May  7 14:41:29 2001
--- pythonrun.c Mon May  7 14:42:39 2001
***************
*** 147,152 ****
--- 147,153 ----
 
        /* phase 2 of builtins */
        _PyImport_FixupExtension
("__builtin__", "__builtin__");
+       _PyImport_FixupExtension
("exceptions", "exceptions");
 
        initsigs(); /* Signal handling stuff, 
including initintr() */           

Without this patch, you might get this exception:

Traceback (most recent call last):
  File "/export/home/jhe/ns/httpd-
8332.195.226.107.82/cgi-bin/extest.py", line 1, in ?
    import exceptions
ImportError: Cannot re-init internal module 
exceptions                          

This bug was probably introduced when exception.py 
became a built-in extension module. Applies to both 
2.0 and 2.1 code.

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

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


From noreply@sourceforge.net  Wed May  9 17:07:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:07:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-232786 ] 2.1a2 "make test" failures under Solaris 8
Message-ID: <E14xWUz-0003F7-00@usw-sf-web3.sourceforge.net>

Bugs item #232786, was updated on 2001-02-16 16:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232786&group_id=5470

Category: Extension Modules
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: 2.1a2 "make test" failures under Solaris 8

Initial Comment:
Platform: SunOS asafoetida 5.8 Generic_108528-04 sun4u sparc SUNW,Ultra-60
(actually a Sun 220 rackmount server)
Compiler: gcc version 2.95.2 19991024 (release)
2.1a2: CVS version from Feb 16

"make test" produces (inter alia):

test_sunaudiodev
test test_sunaudiodev failed -- (2, 'No such file or directory', '/dev/audio')
--- This is probably OK, since the platform is a server, and setup.py uses only the test "if platform == 'sunos5':" to decide to compile the sunaudiodev extension. Maybe it should also test for /dev/audio existence?

test_ucn
test test_ucn crashed -- exceptions.AssertionError: failed to raise an exception
 when given a bogus character name

Running this test manually produces:
./python Lib/test/test_ucn.py
Testing General Unicode Character Name, and case insensitivity... done.
Testing name to code mapping.... done.
Testing code to name mapping for all characters.... done.
Found 10538 characters in the unicode name database
Testing misc. symbols for unicode character name expansion.... done.
Testing unicode character name expansion strict error handling....
Traceback (most recent call last):
  File "Lib/test/test_ucn.py", line 90, in ?
    raise AssertionError, "failed to raise an exception when given a bogus character name"
AssertionError: failed to raise an exception when given a bogus character name



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

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

Message:
Logged In: YES 
user_id=3066

OK, so I fixed the test_sunaudiodev portion of this 3.5
weeks ago and didn't bother to close the bug report.  The
fix was checked in as Lib/test/test_sunaudiodev.py revision
1.10; if the test could not locate an audio device, the test
is skipped rather than failing.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-28 12:24

Message:
Logged In: YES 
user_id=3066

Never mind... maybe SF should hide the comment box after all the comments that have already been written.

Ok, there's only the /dev/audio issue.  Assigned to me since I jumped the gun assigning it elsewhere.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-28 12:19

Message:
Logged In: YES 
user_id=3066

Marc-Andre, can you look at the Unicode part of this?

I don't know what the right thing to do about the /dev/audio issue is, so if anyone can advise us on that we'd appreciate it.

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

Comment By: Mark Favas (mfavas)
Date: 2001-02-18 23:17

Message:
The test_ucn bug has been fixed by /F, after a subsequent report of failure on OpenVMS (bug id 132817, Feb 17).

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

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


From noreply@sourceforge.net  Wed May  9 17:14:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:14:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-422686 ] sys.path initialization in embedded Pyth
Message-ID: <E14xWbI-0007cU-00@usw-sf-web1.sourceforge.net>

Bugs item #422686, was updated on 2001-05-09 09:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422686&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.path initialization in embedded Pyth

Initial Comment:

Context:
======
Python 2.1 final release, working with build from source (c:\program files\python does not exist), 
and PYTHONHOME is set to point to the root source directory (c:\local\src\Python-2.1).
Problem shows up on Windows (other platforms?)

Problem:
======
The directory of the executable (which is not python.exe) shows up in second position in sys.path.

Ex:
==
When the process executable (__argv value) is c:\jdk1.3.0_02\bin\java.exe, I get:

sys.path = ['c:\local\src\jpe', 'c:\local\src\python-2.1\dlls', 'c:\local\src\python-2.1\lib', 
'c:\local\src\python-2.1\lib\plat-win', 'c:\local\src\python-2.1\lib\lib-tk', 
'c:\jdk1.3.0_02\bin', 'c:\local\src\python-2.1']


Note:
===
If PYTHONHOME is not set in the environment, I get a 'site module not found' message upon Python 
initialization, and then a corrupted import behavior, with corrupted values in sys.modules.
Maybe the Python VM should exit right away when the site module cannot be imported, instead of 
going on and working with a corrupted sys.modules list.

I did not have this problem on Python 1.5.2.

I looked at the sys.path initialization C code (getpath() function, windows-specific code...); the 
code seems quite complex, and I could not trace easily where the executable's directory was 
picked up.

By default of finding the source of the problem, an external fix could be a rule of the kind: Do not 
add the executable directory to sys.path when the executable basename not in (python, 
python.exe).

Frederic Giacometti


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

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


From noreply@sourceforge.net  Wed May  9 17:54:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 09:54:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-421999 ] wrong priority doc for ** vs unary -
Message-ID: <E14xXEU-0008HR-00@usw-sf-web1.sourceforge.net>

Bugs item #421999, was updated on 2001-05-07 05:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421999&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: wrong priority doc for ** vs unary -

Initial Comment:
http://www.python.org/doc/current/ref/summary.html 
documents ** as higher-priority than unary - (by 
placing it in the following line on the precedence 
table).  This is unfortunately false: ** is higher 
priority, so e.g. -2**2 evaluates to -4.  Alas, and 
quite confusing to newbies, but at least it needs to 
be documented right.


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

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

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/ref/ref5.tex revisions 1.45 (development
branch) and 1.43.2.1 (maintenance branch).

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

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


From noreply@sourceforge.net  Wed May  9 18:11:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 10:11:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-422702 ] dbhash.open default
Message-ID: <E14xXUs-0005Zb-00@usw-sf-web2.sourceforge.net>

Bugs item #422702, was updated on 2001-05-09 10:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422702&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Nobody/Anonymous (nobody)
Summary: dbhash.open default

Initial Comment:
The function "dbhash.open" is described in the docs as:

   open(path, flag[, mode])
   ...
   The flag argument can be 'r' (the default),...

These two statements are inconsistent because 'flag' 
is not shown in the usage as a default.

Also, the dbhash.open function is declared in the code 
as:

   def open(file, flag, mode=0666):

which does not currently implement flag as a default.

Therefore, I recommend the following:

1) Change the declaration to:

   def open(file, flag='r', mode=0666):

This is consistent with the documented default, and 
also with anydbm.open.

2) Change the dbmhash doc to show the usage as:

   open(path[, flag[, mode]])

This notation is consistent with the current 
description, and with the suggested change in 
implementation.

Thanks!

=g2


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

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


From noreply@sourceforge.net  Wed May  9 18:19:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 10:19:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-422669 ] Bug with appending objects to list.
Message-ID: <E14xXcl-0004A6-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Pavel Khmelinsky (russhmepas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug with appending objects to list.

Initial Comment:
Please, excuse me if this problem is problem of my brain and not a bug....

1st source:
*******************
>>> class cl:
... 	i = 0
...	def grown(self):
...		self.i = self.i + 1
...
...c = cl()
...db = []
...j = 0
...for i in range(0, 10):
...	c.grown()
...	db.append(c)
...	print vars( db[j] )
...	j = j + 1
{'i': 1}
{'i': 2}
{'i': 3}
{'i': 4}
{'i': 5}
{'i': 6}
{'i': 7}
{'i': 8}
{'i': 9}
{'i': 10}
*****************

All rights!

Lets try to see whats the members of the list "db" after end of cycle:

*****************
>>> class cl:
... 	i = 0
... 	def grown(self):
... 		self.i = self.i + 1
... 
... c = cl()
... db = []
... for i in range(0, 10):
... 	c.grown()
... 	db.append(c)
... 
... for j in db:
... 	print vars(j)
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
********************

Why!? Why all members of list are similiar?
This problem doesn'n exist if I appending to list a sipmle type variable (like integer), not
a class object.

P.S.: Sorry for my English, my 1st language is Russian. 
P.P.S.: I am using W2k professional 

Regards,
Pavel Khmelinsky

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

>Comment By: Pavel Khmelinsky (russhmepas)
Date: 2001-05-09 10:19

Message:
Logged In: YES 
user_id=215002

jhylton,
Why? Why "same"? Yes, same object, but with another properties. Before append I called "grow()" method, 
which change "i" variable.
May be list db contain not object, but simple point (link) to object in memory? But I append not point! I 
append Object, so object must be copied to list, isn't it?
If when I append something to list, appending point instead object, why this example
*********************
>>> m=[]
... for j in range(0,10):
...     m.append(j)
... 
... for k in range(0,10):
...     print m[k]
0
1
2
3
4
5
6
7
8
9
******************

working right?

P.S.: I am using python 1.5.2
Thank you for you help!
BG,
Pavel Khmelinsky

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-09 08:37

Message:
Logged In: YES 
user_id=31392

In the second example, you've append the *same object* to
the list
each time. 


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

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


From noreply@sourceforge.net  Wed May  9 18:23:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 10:23:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-422669 ] Bug with appending objects to list.
Message-ID: <E14xXgs-0005jd-00@usw-sf-web2.sourceforge.net>

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

>Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Pavel Khmelinsky (russhmepas)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Bug with appending objects to list.

Initial Comment:
Please, excuse me if this problem is problem of my brain and not a bug....

1st source:
*******************
>>> class cl:
... 	i = 0
...	def grown(self):
...		self.i = self.i + 1
...
...c = cl()
...db = []
...j = 0
...for i in range(0, 10):
...	c.grown()
...	db.append(c)
...	print vars( db[j] )
...	j = j + 1
{'i': 1}
{'i': 2}
{'i': 3}
{'i': 4}
{'i': 5}
{'i': 6}
{'i': 7}
{'i': 8}
{'i': 9}
{'i': 10}
*****************

All rights!

Lets try to see whats the members of the list "db" after end of cycle:

*****************
>>> class cl:
... 	i = 0
... 	def grown(self):
... 		self.i = self.i + 1
... 
... c = cl()
... db = []
... for i in range(0, 10):
... 	c.grown()
... 	db.append(c)
... 
... for j in db:
... 	print vars(j)
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
********************

Why!? Why all members of list are similiar?
This problem doesn'n exist if I appending to list a sipmle type variable (like integer), not
a class object.

P.S.: Sorry for my English, my 1st language is Russian. 
P.P.S.: I am using W2k professional 

Regards,
Pavel Khmelinsky

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

Comment By: Pavel Khmelinsky (russhmepas)
Date: 2001-05-09 10:19

Message:
Logged In: YES 
user_id=215002

jhylton,
Why? Why "same"? Yes, same object, but with another properties. Before append I called "grow()" method, 
which change "i" variable.
May be list db contain not object, but simple point (link) to object in memory? But I append not point! I 
append Object, so object must be copied to list, isn't it?
If when I append something to list, appending point instead object, why this example
*********************
>>> m=[]
... for j in range(0,10):
...     m.append(j)
... 
... for k in range(0,10):
...     print m[k]
0
1
2
3
4
5
6
7
8
9
******************

working right?

P.S.: I am using python 1.5.2
Thank you for you help!
BG,
Pavel Khmelinsky

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-09 08:37

Message:
Logged In: YES 
user_id=31392

In the second example, you've append the *same object* to
the list
each time. 


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

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


From noreply@sourceforge.net  Wed May  9 18:31:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 10:31:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-421878 ] File in a directory with a special chara
Message-ID: <E14xXoD-0000UB-00@usw-sf-web1.sourceforge.net>

Bugs item #421878, was updated on 2001-05-06 13:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421878&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gábor BORGULYA (borgulya)
Assigned to: Nobody/Anonymous (nobody)
Summary: File in a directory with a special chara

Initial Comment:
Using IDLE I tryed to save my work in the directory

C:\Documents and Settings\tdk.000\Dokumentumok\python\saját

but it failed:

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\program files\python21\lib\lib-tk\Tkinter.py", line 1285, in __call__
    return apply(self.func, args)
  File "C:\PROGRA~1\Python21\Tools\idle\IOBinding.py", line 145, in save_a_copy
    self.writefile(filename)
  File "C:\PROGRA~1\Python21\Tools\idle\IOBinding.py", line 152, in writefile
    f = open(filename, "w")
UnicodeError: ASCII encoding error: ordinal not in range(128)

After a log of tries I have renamed the directory: (sajat instead of saját)

C:\Documents and Settings\tdk.000\Dokumentumok\python\saját

and the file was finally saved.

I use WIN2000P.

I hope you can fix it.

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

>Comment By: Gábor BORGULYA (borgulya)
Date: 2001-05-09 10:31

Message:
Logged In: YES 
user_id=131307

Summary:
IDLE couldn't save into the directory
  C:\Documents and Settings\tdk.000\Dokumentumok\python\saját
but when it was renamed to
  C:\Documents and Settings\tdk.000\Dokumentumok\python\sajat
(without the accent above the last "a") it suceeded.

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

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


From noreply@sourceforge.net  Wed May  9 18:54:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 10:54:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-422320 ] 2.2a0 #include termio.h fails on FreeBSD
Message-ID: <E14xYAK-0004d7-00@usw-sf-web3.sourceforge.net>

Bugs item #422320, was updated on 2001-05-08 07:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422320&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 2.2a0 #include termio.h fails on FreeBSD

Initial Comment:
Recent change to termios module to #include termio.h
causes compilation to fail on FreeBSD where termio.h
does not exist. Other platforms may well be similar... 
termio.h seems to be a backward compatible type file -
does it really need to be included?

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

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

Message:
Logged In: YES 
user_id=3066

Fixed in Modules/termios.c revision 2.26; termio.h is only
included for OSF, where it is required.

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

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


From noreply@sourceforge.net  Wed May  9 19:04:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 11:04:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-421973 ] Coercion rules incomplete
Message-ID: <E14xYKF-0004mI-00@usw-sf-web3.sourceforge.net>

Bugs item #421973, was updated on 2001-05-07 02:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421973&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Coercion rules incomplete

Initial Comment:
The description of the coercion rules for numeric types
at
http://www.python.org/doc/current/ref/numeric-types.html
is incomplete. Step 3 says "We only get here if neither
x nor y is a class instance. " But step 2a also refers
to step 3 for the case that an explicit coercion
function returns None. It is not clear what happens in
that case.


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

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

Message:
Logged In: YES 
user_id=3066

Guido, can you correct this?  I'm afraid I might get it
wrong.  The coercion rules are strange turf for me.  ;-(

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

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


From noreply@sourceforge.net  Wed May  9 19:14:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 11:14:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-416530 ] No notes for building on Mac OS X 10.0
Message-ID: <E14xYU8-0004uF-00@usw-sf-web3.sourceforge.net>

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

Category: Documentation
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: No notes for building on Mac OS X 10.0

Initial Comment:
In the 'README' file for Python-2.1c2, the 'Platform 
specific notes' section for Mac OS X should be 
amended to include notes for building on Mac OS 
10.0 (as opposed to Mac OS X beta). The 
suggested new words are:

Run configure with "OPT='-no-cpp-precomp' ./
configure --with-suffix=.exe --with-dyld".
This generates executable file: 'python.exe' (it 
cannot be named 'python' on an HFS or HFS+
disk as the file name clashes with directory 
'Python'). The '-no-cpp-precomp' option prevents
a large number of compilation warnings.

All the regression tests succeed except for the 
regular expression test 'test_re'
which fails with a SEGV unless file '_sre.c' has a fix 
to limit the depth of recursion used.
This change (and a suggested fix) has been 
submitted as a bug under request id: 416526.

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

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

Message:
Logged In: YES 
user_id=3066

Fixed in README revisions 1.124 (development branch) and
1.122.2.1 (2.1 maintenance branch).

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-21 05:43

Message:
Logged In: YES 
user_id=21627

I think that configure.in should be corrected to
automatically use the right options, instead of documenting
how to manually pass them.


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

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


From noreply@sourceforge.net  Wed May  9 20:15:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 12:15:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-416573 ] makesockaddr() AF_UNIX ignores sun_len
Message-ID: <E14xZQw-0007I2-00@usw-sf-web2.sourceforge.net>

Bugs item #416573, was updated on 2001-04-16 18:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416573&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: makesockaddr() AF_UNIX ignores sun_len

Initial Comment:
On FreeBSD 4.2-RELEASE, bind two AF_UNIX,SOCK_DGRAM
sockets and send a packet over.  The recvfrom() call
returns a corrupted pathname.

This seems to fix the problem:

return PyString_FromStringAndSize (a->sun_path,
a->sun_len - (sizeof a->sun_len + sizeof
a->sun_family));

Another fix would be to zero out the address buffer in
recvfrom() [and any other places that call
makesockaddr]

-Sam


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

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

Message:
Logged In: YES 
user_id=3066

Fixed by clearing the address buffers before making the
system call that fills them in; this technique has
precedents in this module.  Fixed three occurances.

Checked in as Modules/socketmodule.c revisions 1.142
(development branch) and 1.141.2.1 (2.1 maintenance branch).


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

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


From noreply@sourceforge.net  Wed May  9 21:19:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 13:19:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-422678 ] argv is modified in Py_Main()
Message-ID: <E14xaQT-00088d-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: argv is modified in Py_Main()

Initial Comment:
Context: Python 2.1 release

In function Py_Main( argc, argv), @[file main.c, line 287], argv is modified: 		
'argv[_PyOS_optind] = "-c";'

argv[] should remain constant, and should not be modified; I am getting a coredump when cleaning 
up the contents of argv[] in the calling process...

If you feel you need to modify argv[]; a copy of the array should be made at the beginning of 
Py_Main(), and then work/modify the copy; not the original !!!

Meanwhile, I'll pass a copy of argv to Py_Main(), and will clean up the original!!

FG


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

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

Message:
Logged In: YES 
user_id=31435

The C standard doesn't support your claim.  Here from C99,
section 5.1.2.2.1 (Program startup):

"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""

You may not *like* programs to change them, but given that 
the std explicitly allows it you're fighting the universe 
(that is, it's you who are relying on non-standard 
behavior, not Python).

Assigned to Guido for Pronouncement.


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

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


From noreply@sourceforge.net  Wed May  9 22:06:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 14:06:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-422669 ] Bug with appending objects to list.
Message-ID: <E14xbAX-00040Y-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Pavel Khmelinsky (russhmepas)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Bug with appending objects to list.

Initial Comment:
Please, excuse me if this problem is problem of my brain and not a bug....

1st source:
*******************
>>> class cl:
... 	i = 0
...	def grown(self):
...		self.i = self.i + 1
...
...c = cl()
...db = []
...j = 0
...for i in range(0, 10):
...	c.grown()
...	db.append(c)
...	print vars( db[j] )
...	j = j + 1
{'i': 1}
{'i': 2}
{'i': 3}
{'i': 4}
{'i': 5}
{'i': 6}
{'i': 7}
{'i': 8}
{'i': 9}
{'i': 10}
*****************

All rights!

Lets try to see whats the members of the list "db" after end of cycle:

*****************
>>> class cl:
... 	i = 0
... 	def grown(self):
... 		self.i = self.i + 1
... 
... c = cl()
... db = []
... for i in range(0, 10):
... 	c.grown()
... 	db.append(c)
... 
... for j in db:
... 	print vars(j)
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
{'i': 10}
********************

Why!? Why all members of list are similiar?
This problem doesn'n exist if I appending to list a sipmle type variable (like integer), not
a class object.

P.S.: Sorry for my English, my 1st language is Russian. 
P.P.S.: I am using W2k professional 

Regards,
Pavel Khmelinsky

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

>Comment By: Pavel Khmelinsky (russhmepas)
Date: 2001-05-09 14:06

Message:
Logged In: YES 
user_id=215002

Please, sorry for my nonsense.
Now I understand what it is not bug.
If somebody interesting the right code is:
*************
>>> import copy
... class cl:
...     i = 0
...     def grown(self):
...         self.i = self.i + 1
... 
... c = cl()
... db = []
... for i in range(0, 10):
...     c.grown()
...     db.append(copy.deepcopy(c))
... 
... for j in db:
...     print vars(j)
{'i': 1}
{'i': 2}
{'i': 3}
{'i': 4}
{'i': 5}
{'i': 6}
{'i': 7}
{'i': 8}
{'i': 9}
{'i': 10}
***************

Big thanks for Jeremy. (Words "name binding" and "mutable" very helps me)


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

Comment By: Pavel Khmelinsky (russhmepas)
Date: 2001-05-09 10:19

Message:
Logged In: YES 
user_id=215002

jhylton,
Why? Why "same"? Yes, same object, but with another properties. Before append I called "grow()" method, 
which change "i" variable.
May be list db contain not object, but simple point (link) to object in memory? But I append not point! I 
append Object, so object must be copied to list, isn't it?
If when I append something to list, appending point instead object, why this example
*********************
>>> m=[]
... for j in range(0,10):
...     m.append(j)
... 
... for k in range(0,10):
...     print m[k]
0
1
2
3
4
5
6
7
8
9
******************

working right?

P.S.: I am using python 1.5.2
Thank you for you help!
BG,
Pavel Khmelinsky

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-09 08:37

Message:
Logged In: YES 
user_id=31392

In the second example, you've append the *same object* to
the list
each time. 


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

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


From noreply@sourceforge.net  Wed May  9 22:11:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 14:11:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-231328 ] fcntl module functions should accept file module arguments.
Message-ID: <E14xbEa-00045y-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 2
Submitted By: Eric S. Raymond (esr)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: fcntl module functions should accept file module arguments.

Initial Comment:
The functions in the standard library fcntl module require integer
(file descriptor) arguments.  They should accept arguments with a
fileno() method as well, in particular file objects.


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

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

Message:
Logged In: YES 
user_id=3066

Checked in as Modules/fcntlmodule.c revision 2.29.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-04-11 13:08

Message:
Logged In: YES 
user_id=3066

Assigned to me so it at least appears on someone's list.  Set resolution to "Later" since it's too late for Python 2.1, but it should be done for 2.2.

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

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

Message:
Logged In: YES 
user_id=6380

This would be a simple patch. Anyone care to provide one?

(Too late for 2.1 though -- sorry.)


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

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

Message:
Logged In: YES 
user_id=11375

I've let this gather dust long enough; unassigning so
someone else can take responsibility for it.

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

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

Message:
Logged In: YES 
user_id=11375

I've let this gather dust long enough; unassigning so
someone else can take responsibility for it.

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

Comment By: Tim Peters (tim_one)
Date: 2001-02-08 19:02

Message:
Care to add mmap.mmap while you're at it?

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-08 09:24

Message:
Assigning to akuchling.

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

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


From noreply@sourceforge.net  Thu May 10 00:01:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 16:01:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-422088 ] [OSF1 alpha] string.replace()
Message-ID: <E14xcxr-00009q-00@usw-sf-web3.sourceforge.net>

Bugs item #422088, was updated on 2001-05-07 11:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422088&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Martin Casado (martin_casado)
>Assigned to: Tim Peters (tim_one)
Summary: [OSF1 alpha] string.replace()

Initial Comment:
>>> import sys
>>> sys.version
'2.0c1 (#7, Jan 24 2001, 15:36:12) [C]'
>>> s = "123"
>>> s.replace("123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError
>>> os.uname()
('OSF1', 'xxx', 'V4.0', '1229', 'alpha')
>>> 


I haven't tried it with anything newer, perhaps this
bug
has already been posted and/or fixed, though I couldn't
find it in the buglist

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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-09 16:01

Message:
Logged In: YES 
user_id=31435

Good eye, Michael!  I've checked in what I hope will be a 
fix:

Lib/test/string_tests.py new revision: 1.8
Modules/stropmodule.c new revision: 2.77

Please give that a try and let me know whether it fixes the 
problem on this box.


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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 07:51

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 00:34

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 19:58

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try recompiling with optimization 
turned off.  If that makes the problem go away (seems 
likely to me), it's a platform compiler bug.

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

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


From noreply@sourceforge.net  Thu May 10 00:07:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 16:07:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-422821 ] re.sub raise error with repl is '\'
Message-ID: <E14xd33-0001qJ-00@usw-sf-web2.sourceforge.net>

Bugs item #422821, was updated on 2001-05-09 16:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422821&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: eXom (jkuan)
Assigned to: Nobody/Anonymous (nobody)
Summary: re.sub raise error with repl is '\'

Initial Comment:
I try to regular substitution '/' into '\'. So I did
re.sub('/', '\', '/tmp/hello').

An exception is raised as follows:

>>> re.sub('/', '\', '/tmp/hello')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.0/sre.py", line 50, in
sub
    return _compile(pattern, 0).sub(repl, string,
count)
  File "/usr/local/lib/python2.0/sre.py", line 115, in
_sub
    return _subn(pattern, template, string, count)[0]
  File "/usr/local/lib/python2.0/sre.py", line 122, in
_subn
    template = sre_parse.parse_template(template,
pattern)
  File "/usr/local/lib/python2.0/sre_parse.py", line
606, in parse_template
    s = Tokenizer(source)
  File "/usr/local/lib/python2.0/sre_parse.py", line
164, in __init__
    self.__next()
  File "/usr/local/lib/python2.0/sre_parse.py", line
174, in __next
    raise error, "bogus escape"
sre_constants.error: bogus escape

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

But if I do re.sub('/', '\\', '/tmp/hello')

>>> re.sub('/', '\\', '/tmp/hello')
'\tmp\hello'

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

I am using BeOpen-Python-2.0-1 (install rpm file) on
Linux i386 machine.


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

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


From noreply@sourceforge.net  Thu May 10 00:16:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 16:16:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-422821 ] re.sub raise error with repl is '\'
Message-ID: <E14xdCG-0006DU-00@usw-sf-web1.sourceforge.net>

Bugs item #422821, was updated on 2001-05-09 16:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422821&group_id=5470

Category: Regular Expressions
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: eXom (jkuan)
Assigned to: Nobody/Anonymous (nobody)
Summary: re.sub raise error with repl is '\'

Initial Comment:
I try to regular substitution '/' into '\'. So I did
re.sub('/', '\', '/tmp/hello').

An exception is raised as follows:

>>> re.sub('/', '\', '/tmp/hello')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.0/sre.py", line 50, in
sub
    return _compile(pattern, 0).sub(repl, string,
count)
  File "/usr/local/lib/python2.0/sre.py", line 115, in
_sub
    return _subn(pattern, template, string, count)[0]
  File "/usr/local/lib/python2.0/sre.py", line 122, in
_subn
    template = sre_parse.parse_template(template,
pattern)
  File "/usr/local/lib/python2.0/sre_parse.py", line
606, in parse_template
    s = Tokenizer(source)
  File "/usr/local/lib/python2.0/sre_parse.py", line
164, in __init__
    self.__next()
  File "/usr/local/lib/python2.0/sre_parse.py", line
174, in __next
    raise error, "bogus escape"
sre_constants.error: bogus escape

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

But if I do re.sub('/', '\\', '/tmp/hello')

>>> re.sub('/', '\\', '/tmp/hello')
'\tmp\hello'

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

I am using BeOpen-Python-2.0-1 (install rpm file) on
Linux i386 machine.


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

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

Message:
Logged In: YES 
user_id=31435

Not a bug.  The msg from re is correct:  the regexp you 
passed has no meaning, due to a bogus escape (you passed it 
a lone backslash, but a backslash is a regexp 
metacharacter:  if you want re to use a literal backslash, 
you must escape it with a backslash too).

Get in the habit of using r-strings for regular expressions:

re.sub('/', r'\', '/tmp/hello')

works fine (read the docs for more on r-strings and 
backslash escapes; also see the FAQ).


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

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


From noreply@sourceforge.net  Thu May 10 03:26:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 19:26:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-420490 ] lookdict_string does not use interning
Message-ID: <E14xg9k-0002R2-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Tim Peters (tim_one)
Summary: lookdict_string does not use interning

Initial Comment:
In Python 2.1, when a dictionary uses lookdict_string 
to retrieve items, the function used to compare 
strings is PyString_Type.tp_compare, i.e. 
string_compare.  string_compare does not check if its 
parameters are actually the same PStringObject *, so 
an actual string comparison is made even if the 
dictionary's keys have been interned.  Python 1.52 
used PyObject_Compare to compare all keys, and this 
function did check to see if its parameters were the 
same PyObject *.

I wonder if this might be one source of the slow-down 
in Python 2.1?


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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-09 19:26

Message:
Logged In: YES 
user_id=31435

Closed as requested.  Cheer up, though!  You're certainly 
not the first one to miss this trick.  The dict code is 
subtle to the point of looking straightforward <wink>.


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

Comment By: Greg Chapman (glchapman)
Date: 2001-05-01 10:20

Message:
Logged In: YES 
user_id=86307

Actually, I apologize for wasting everyone's time.  This 
report is totally false; I missed this line:

	if (ep->me_key == NULL || ep->me_key == key)
		return ep;

Please ignore this.  I'm going to go get some sleep.



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

Comment By: Greg Chapman (glchapman)
Date: 2001-05-01 10:17

Message:
Logged In: YES 
user_id=86307

Actually, to be more specific, only the first comparison in 
lookdict_string forgets to see if the string pointers are 
the same.  I assume the proper fix would be to change this 
first comparison to be:

 	if (ep->me_key == dummy)
 		freeslot = ep;
 	else {
-		if (ep->me_hash == hash
-		    && compare(ep->me_key, key) == 0) {
+		if (ep->me_key == key
+                    || (ep->me_hash == hash
+		    && compare(ep->me_key, key) == 0)) {
 			return ep;
 		}
 		freeslot = NULL;
 	}


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

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


From noreply@sourceforge.net  Thu May 10 07:12:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 09 May 2001 23:12:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-422121 ] Insecurities in dict comparison
Message-ID: <E14xjga-0006qv-00@usw-sf-web2.sourceforge.net>

Bugs item #422121, was updated on 2001-05-07 14:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422121&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: Insecurities in dict comparison

Initial Comment:
Dict comparison is complicated, and the comparison 
code holds on to pointers to keys and values 
across "dangerous" calls without incrementing 
refcounts first.  For example, characterize() hangs on 
to each key across two calls to 
PyObject_RichCompareBool() and one to PyDict_GetItem
(), and any of those could call back into Python code 
and delete key in the meantime.  Unref'ed pointers to 
a key and a value may also be passed back to 
characterize()'s caller.  dict_compare() can hold on 
to these passed-back pointers across calls to 
PyObject_Compare() too.

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

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

Message:
Logged In: YES 
user_id=31435

Boosted the priority and assigned to me:  my first attempt 
to provoke problems here yielded a program that crashes (on 
Windows) at various times in Python, in the MS C library, 
in KERNEL32.DLL, gets the system so confused it doesn't 
know *where* it's blowing up, got into an infinite loop a 
few times, ... and finally convinced me it's a *serious* 
problem when it caused a spontaneous reboot <wink>.


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

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

Message:
Logged In: YES 
user_id=31435

Unassigned again, because I don't expect to get to this in 
the foreseeable future (if I thought I would, I would have 
assigned it to me when I entered it).


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

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


From noreply@sourceforge.net  Thu May 10 08:11:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 00:11:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-422088 ] [OSF1 alpha] string.replace()
Message-ID: <E14xkby-0007ds-00@usw-sf-web2.sourceforge.net>

Bugs item #422088, was updated on 2001-05-07 11:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422088&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Martin Casado (martin_casado)
Assigned to: Tim Peters (tim_one)
Summary: [OSF1 alpha] string.replace()

Initial Comment:
>>> import sys
>>> sys.version
'2.0c1 (#7, Jan 24 2001, 15:36:12) [C]'
>>> s = "123"
>>> s.replace("123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError
>>> os.uname()
('OSF1', 'xxx', 'V4.0', '1229', 'alpha')
>>> 


I haven't tried it with anything newer, perhaps this
bug
has already been posted and/or fixed, though I couldn't
find it in the buglist

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-10 00:11

Message:
Logged In: YES 
user_id=6656

yep, fixes it.  doesn't fix strop, but I think that's
deliberate?

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 16:01

Message:
Logged In: YES 
user_id=31435

Good eye, Michael!  I've checked in what I hope will be a 
fix:

Lib/test/string_tests.py new revision: 1.8
Modules/stropmodule.c new revision: 2.77

Please give that a try and let me know whether it fixes the 
problem on this box.


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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 07:51

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 00:34

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 19:58

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try recompiling with optimization 
turned off.  If that makes the problem go away (seems 
likely to me), it's a platform compiler bug.

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

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


From noreply@sourceforge.net  Thu May 10 09:34:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 01:34:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-422121 ] Insecurities in dict comparison
Message-ID: <E14xluN-0006pn-00@usw-sf-web3.sourceforge.net>

Bugs item #422121, was updated on 2001-05-07 14:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422121&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Insecurities in dict comparison

Initial Comment:
Dict comparison is complicated, and the comparison 
code holds on to pointers to keys and values 
across "dangerous" calls without incrementing 
refcounts first.  For example, characterize() hangs on 
to each key across two calls to 
PyObject_RichCompareBool() and one to PyDict_GetItem
(), and any of those could call back into Python code 
and delete key in the meantime.  Unref'ed pointers to 
a key and a value may also be passed back to 
characterize()'s caller.  dict_compare() can hold on 
to these passed-back pointers across calls to 
PyObject_Compare() too.

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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-10 01:34

Message:
Logged In: YES 
user_id=31435

Lib/test/test_mutants.py, initial revision: 1.1
Lib/test/output/test_mutants, initial revision: 1.1
Misc/NEWS, new revision: 1.164
Objects/dictobject.c, new revision: 2.84


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

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

Message:
Logged In: YES 
user_id=31435

Boosted the priority and assigned to me:  my first attempt 
to provoke problems here yielded a program that crashes (on 
Windows) at various times in Python, in the MS C library, 
in KERNEL32.DLL, gets the system so confused it doesn't 
know *where* it's blowing up, got into an infinite loop a 
few times, ... and finally convinced me it's a *serious* 
problem when it caused a spontaneous reboot <wink>.


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

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

Message:
Logged In: YES 
user_id=31435

Unassigned again, because I don't expect to get to this in 
the foreseeable future (if I thought I would, I would have 
assigned it to me when I entered it).


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

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


From noreply@sourceforge.net  Thu May 10 10:02:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 02:02:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-422088 ] [OSF1 alpha] string.replace()
Message-ID: <E14xmKk-0007BS-00@usw-sf-web3.sourceforge.net>

Bugs item #422088, was updated on 2001-05-07 11:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422088&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Martin Casado (martin_casado)
Assigned to: Tim Peters (tim_one)
Summary: [OSF1 alpha] string.replace()

Initial Comment:
>>> import sys
>>> sys.version
'2.0c1 (#7, Jan 24 2001, 15:36:12) [C]'
>>> s = "123"
>>> s.replace("123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError
>>> os.uname()
('OSF1', 'xxx', 'V4.0', '1229', 'alpha')
>>> 


I haven't tried it with anything newer, perhaps this
bug
has already been posted and/or fixed, though I couldn't
find it in the buglist

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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-10 02:02

Message:
Logged In: YES 
user_id=31435

Sorry, don't know what "doesn't fix strop" means.  What's 
broken in strop?  The test case didn't use strop (although 
I mentioned stropmodule.c in a comment).  Closing the bug 
assuming this is some misunderstanding that's not worth the 
time to straighten out <0.7 wink>; please re-open if you 
think it is.

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-10 00:11

Message:
Logged In: YES 
user_id=6656

yep, fixes it.  doesn't fix strop, but I think that's
deliberate?

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 16:01

Message:
Logged In: YES 
user_id=31435

Good eye, Michael!  I've checked in what I hope will be a 
fix:

Lib/test/string_tests.py new revision: 1.8
Modules/stropmodule.c new revision: 2.77

Please give that a try and let me know whether it fixes the 
problem on this box.


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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 07:51

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 00:34

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 19:58

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try recompiling with optimization 
turned off.  If that makes the problem go away (seems 
likely to me), it's a platform compiler bug.

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

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


From noreply@sourceforge.net  Thu May 10 11:45:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 03:45:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-422088 ] [OSF1 alpha] string.replace()
Message-ID: <E14xnwN-0008WM-00@usw-sf-web3.sourceforge.net>

Bugs item #422088, was updated on 2001-05-07 11:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422088&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Martin Casado (martin_casado)
Assigned to: Tim Peters (tim_one)
Summary: [OSF1 alpha] string.replace()

Initial Comment:
>>> import sys
>>> sys.version
'2.0c1 (#7, Jan 24 2001, 15:36:12) [C]'
>>> s = "123"
>>> s.replace("123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError
>>> os.uname()
('OSF1', 'xxx', 'V4.0', '1229', 'alpha')
>>> 


I haven't tried it with anything newer, perhaps this
bug
has already been posted and/or fixed, though I couldn't
find it in the buglist

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-10 03:45

Message:
Logged In: YES 
user_id=6656

I meant:

Python 2.2a0 (#3, May 10 2001, 07:57:08) [C] on osf1V4
Type "copyright", "credits" or "license" for more information.
>>> import strop
>>> strop.replace("123","123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

as I said, I thought this was expected, but thought I'd check (I 
did put a comment in yesterday that explained what I meant more
thouroughly, but sf ate it).


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 02:02

Message:
Logged In: YES 
user_id=31435

Sorry, don't know what "doesn't fix strop" means.  What's 
broken in strop?  The test case didn't use strop (although 
I mentioned stropmodule.c in a comment).  Closing the bug 
assuming this is some misunderstanding that's not worth the 
time to straighten out <0.7 wink>; please re-open if you 
think it is.

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-10 00:11

Message:
Logged In: YES 
user_id=6656

yep, fixes it.  doesn't fix strop, but I think that's
deliberate?

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 16:01

Message:
Logged In: YES 
user_id=31435

Good eye, Michael!  I've checked in what I hope will be a 
fix:

Lib/test/string_tests.py new revision: 1.8
Modules/stropmodule.c new revision: 2.77

Please give that a try and let me know whether it fixes the 
problem on this box.


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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 07:51

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 00:34

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 19:58

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try recompiling with optimization 
turned off.  If that makes the problem go away (seems 
likely to me), it's a platform compiler bug.

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

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


From noreply@sourceforge.net  Thu May 10 12:38:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 04:38:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-422678 ] argv is modified in Py_Main()
Message-ID: <E14xolv-0000kT-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Guido van Rossum (gvanrossum)
Summary: argv is modified in Py_Main()

Initial Comment:
Context: Python 2.1 release

In function Py_Main( argc, argv), @[file main.c, line 287], argv is modified: 		
'argv[_PyOS_optind] = "-c";'

argv[] should remain constant, and should not be modified; I am getting a coredump when cleaning 
up the contents of argv[] in the calling process...

If you feel you need to modify argv[]; a copy of the array should be made at the beginning of 
Py_Main(), and then work/modify the copy; not the original !!!

Meanwhile, I'll pass a copy of argv to Py_Main(), and will clean up the original!!

FG


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

>Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:38

Message:
Logged In: YES 
user_id=93657

There are three ways to consider Tim's answer:

- I know of general law of the universe of programming (something that goes beyond the C programming 
world, and above whatever standardization committee); that says something like 
"memory ownership of the parameters will belong either to the callee or the caller, and this ownership will 
not be modified by the callee".

- It is not because a 'local jurisdiction' allows to do a stupid thing (i.e. locally modifying arrays passed by a 
caller) that one is compelled or excused for doing it (and I'll refrain from american bashing on this latter 
point...)

- The #8212 article that Tim mentions (out of its context) applies to the 'main()' function, not to Py_Main(), 
therefore the article #8212 does not apply to this case.

Sorry...

FG


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

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

Message:
Logged In: YES 
user_id=31435

The C standard doesn't support your claim.  Here from C99,
section 5.1.2.2.1 (Program startup):

"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""

You may not *like* programs to change them, but given that 
the std explicitly allows it you're fighting the universe 
(that is, it's you who are relying on non-standard 
behavior, not Python).

Assigned to Guido for Pronouncement.


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

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


From noreply@sourceforge.net  Thu May 10 12:47:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 04:47:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-422678 ] argv is modified in Py_Main()
Message-ID: <E14xovF-0001PV-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Guido van Rossum (gvanrossum)
Summary: argv is modified in Py_Main()

Initial Comment:
Context: Python 2.1 release

In function Py_Main( argc, argv), @[file main.c, line 287], argv is modified: 		
'argv[_PyOS_optind] = "-c";'

argv[] should remain constant, and should not be modified; I am getting a coredump when cleaning 
up the contents of argv[] in the calling process...

If you feel you need to modify argv[]; a copy of the array should be made at the beginning of 
Py_Main(), and then work/modify the copy; not the original !!!

Meanwhile, I'll pass a copy of argv to Py_Main(), and will clean up the original!!

FG


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

>Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:47

Message:
Logged In: YES 
user_id=93657

I think Tim and I might even have misread article #8212.

In effect, having a second read at it:
"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""
The article actually states two things:
1) argv may be modified during execution of main()
2) argv MUST be restored to its initial value upon exit/termination.

So, in spite of all attempts at pursuing ambiguity, article #8212 states that when main() returns, argv must 
have been restored to its initial state/value.

FG




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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:38

Message:
Logged In: YES 
user_id=93657

There are three ways to consider Tim's answer:

- I know of general law of the universe of programming (something that goes beyond the C programming 
world, and above whatever standardization committee); that says something like 
"memory ownership of the parameters will belong either to the callee or the caller, and this ownership will 
not be modified by the callee".

- It is not because a 'local jurisdiction' allows to do a stupid thing (i.e. locally modifying arrays passed by a 
caller) that one is compelled or excused for doing it (and I'll refrain from american bashing on this latter 
point...)

- The #8212 article that Tim mentions (out of its context) applies to the 'main()' function, not to Py_Main(), 
therefore the article #8212 does not apply to this case.

Sorry...

FG


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

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

Message:
Logged In: YES 
user_id=31435

The C standard doesn't support your claim.  Here from C99,
section 5.1.2.2.1 (Program startup):

"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""

You may not *like* programs to change them, but given that 
the std explicitly allows it you're fighting the universe 
(that is, it's you who are relying on non-standard 
behavior, not Python).

Assigned to Guido for Pronouncement.


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

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


From noreply@sourceforge.net  Thu May 10 15:01:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 07:01:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-423033 ] time module docs vs implementation
Message-ID: <E14xr0K-0002i1-00@usw-sf-web3.sourceforge.net>

Bugs item #423033, was updated on 2001-05-10 07:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423033&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: time module docs vs implementation

Initial Comment:
Goal: Print current time

Library reference docs state "time.asctime()" should work

However,
Python 1.5.2 (#1, Feb  1 2000, 16:32:16)  [GCC
egcs-2.91.66 19990314/Linux (egcs- on linux-i386
>>> import time
>>> print time.asctime()

gives "TypeError: function requires at least one argument"

same holds for time.gmtime() and time.localtime() as well

The only way to print current time afaik is
>>> print time.asctime( time.localtime( time.time()) )

which is quite more complicated than promised



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

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


From noreply@sourceforge.net  Thu May 10 17:02:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 09:02:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-423033 ] time module docs vs implementation
Message-ID: <E14xstX-00065r-00@usw-sf-web2.sourceforge.net>

Bugs item #423033, was updated on 2001-05-10 07:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423033&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: time module docs vs implementation

Initial Comment:
Goal: Print current time

Library reference docs state "time.asctime()" should work

However,
Python 1.5.2 (#1, Feb  1 2000, 16:32:16)  [GCC
egcs-2.91.66 19990314/Linux (egcs- on linux-i386
>>> import time
>>> print time.asctime()

gives "TypeError: function requires at least one argument"

same holds for time.gmtime() and time.localtime() as well

The only way to print current time afaik is
>>> print time.asctime( time.localtime( time.time()) )

which is quite more complicated than promised



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

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

Message:
Logged In: YES 
user_id=31392

The current documentation applies to Python 2.1.  If you're
using
Python 1.5.2, you'll need to use the Python 1.5.2 docs.


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

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


From noreply@sourceforge.net  Thu May 10 17:11:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 09:11:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-417779 ] Fails to build on RH 5.1
Message-ID: <E14xt2F-0006DM-00@usw-sf-web2.sourceforge.net>

Bugs item #417779, was updated on 2001-04-20 18:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417779&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Fails to build on RH 5.1

Initial Comment:
Im trying to build and install on RH 5.1
i get the following errors.

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -
I./Include -DHAVE_CONFIG_H  -o Objects/fileobject.o 
Objects/fileobject.c
Objects/fileobject.c: In function `_portable_fseek':
Objects/fileobject.c:229: warning: implicit 
declaration of function `fseeko'

gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -
DHAVE_CONFIG_H   -c ./Modules/posixmodule.c -o 
Modules/posixmodule.o
./Modules/posixmodule.c:4032: sys/statvfs.h: No such 
file or directory
./Modules/posixmodule.c:4081: sys/statvfs.h: No such 
file or directory

Am i missing something?

Regards
Andrew



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

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


From noreply@sourceforge.net  Thu May 10 17:12:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 09:12:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-422088 ] [OSF1 alpha] string.replace()
Message-ID: <E14xt38-0004Wv-00@usw-sf-web3.sourceforge.net>

Bugs item #422088, was updated on 2001-05-07 11:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422088&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Martin Casado (martin_casado)
Assigned to: Tim Peters (tim_one)
Summary: [OSF1 alpha] string.replace()

Initial Comment:
>>> import sys
>>> sys.version
'2.0c1 (#7, Jan 24 2001, 15:36:12) [C]'
>>> s = "123"
>>> s.replace("123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError
>>> os.uname()
('OSF1', 'xxx', 'V4.0', '1229', 'alpha')
>>> 


I haven't tried it with anything newer, perhaps this
bug
has already been posted and/or fixed, though I couldn't
find it in the buglist

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

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

Message:
Logged In: YES 
user_id=31435

Ah!  No, I do NOT expect that.  The copies of mymemreplace
() in stringobject.c and stropmodule.c were (eventually) 
both replaced, and that was the source of the MemoryError.  
Did you have up-to-date versions of both?  If so, this is 
some other bug!  The only occurrence of PyMem_MALLOC() in 
stropmodule.c "got fixed".

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-10 03:45

Message:
Logged In: YES 
user_id=6656

I meant:

Python 2.2a0 (#3, May 10 2001, 07:57:08) [C] on osf1V4
Type "copyright", "credits" or "license" for more information.
>>> import strop
>>> strop.replace("123","123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

as I said, I thought this was expected, but thought I'd check (I 
did put a comment in yesterday that explained what I meant more
thouroughly, but sf ate it).


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 02:02

Message:
Logged In: YES 
user_id=31435

Sorry, don't know what "doesn't fix strop" means.  What's 
broken in strop?  The test case didn't use strop (although 
I mentioned stropmodule.c in a comment).  Closing the bug 
assuming this is some misunderstanding that's not worth the 
time to straighten out <0.7 wink>; please re-open if you 
think it is.

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-10 00:11

Message:
Logged In: YES 
user_id=6656

yep, fixes it.  doesn't fix strop, but I think that's
deliberate?

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 16:01

Message:
Logged In: YES 
user_id=31435

Good eye, Michael!  I've checked in what I hope will be a 
fix:

Lib/test/string_tests.py new revision: 1.8
Modules/stropmodule.c new revision: 2.77

Please give that a try and let me know whether it fixes the 
problem on this box.


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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 07:51

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 00:34

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 19:58

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try recompiling with optimization 
turned off.  If that makes the problem go away (seems 
likely to me), it's a platform compiler bug.

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

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


From noreply@sourceforge.net  Thu May 10 17:51:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 09:51:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-423087 ] A small typo in weakref documentation
Message-ID: <E14xtfA-0006ig-00@usw-sf-web2.sourceforge.net>

Bugs item #423087, was updated on 2001-05-10 09:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423087&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Yakov Markovitch (markovitch)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: A small typo in weakref documentation

Initial Comment:
In the description of weakref.proxy() there is written: 
"callable is the same as the parameter of the same name
to the ref() function."
There must be obviously "callback" instead of "callable".

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

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


From noreply@sourceforge.net  Thu May 10 18:16:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 10:16:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-422678 ] argv is modified in Py_Main()
Message-ID: <E14xu3M-00074T-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Guido van Rossum (gvanrossum)
Summary: argv is modified in Py_Main()

Initial Comment:
Context: Python 2.1 release

In function Py_Main( argc, argv), @[file main.c, line 287], argv is modified: 		
'argv[_PyOS_optind] = "-c";'

argv[] should remain constant, and should not be modified; I am getting a coredump when cleaning 
up the contents of argv[] in the calling process...

If you feel you need to modify argv[]; a copy of the array should be made at the beginning of 
Py_Main(), and then work/modify the copy; not the original !!!

Meanwhile, I'll pass a copy of argv to Py_Main(), and will clean up the original!!

FG


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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-10 10:16

Message:
Logged In: YES 
user_id=31435

Frederic, the meaning of the std is plain:  if you modify a 
value, you store into it, so the last modification is the 
one that must stick "until program termination".  They're 
simply trying to forbid the environment from sticking argv 
in a volatile memory area (which some poor-quality C 
implementations have done in the past).

Note too that if the std *intended* argv to be read-only, 
they would have decorated its declaration with a "const" 
qualifier.  They did not.

The reason I *object* to making Py_Main more expensive is 
that its overwhelmingly most common uses are the calls from 
python.c and WinMain.c, direcly called from their 
respective C main() functions.  In a decade of using 
Python, the copying you want would never have bought me a 
thing, other than code bloat and extra expense on Python 
startup.  You've got the oddball use case here, so you're 
the one who should pay for it.


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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:47

Message:
Logged In: YES 
user_id=93657

I think Tim and I might even have misread article #8212.

In effect, having a second read at it:
"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""
The article actually states two things:
1) argv may be modified during execution of main()
2) argv MUST be restored to its initial value upon exit/termination.

So, in spite of all attempts at pursuing ambiguity, article #8212 states that when main() returns, argv must 
have been restored to its initial state/value.

FG




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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:38

Message:
Logged In: YES 
user_id=93657

There are three ways to consider Tim's answer:

- I know of general law of the universe of programming (something that goes beyond the C programming 
world, and above whatever standardization committee); that says something like 
"memory ownership of the parameters will belong either to the callee or the caller, and this ownership will 
not be modified by the callee".

- It is not because a 'local jurisdiction' allows to do a stupid thing (i.e. locally modifying arrays passed by a 
caller) that one is compelled or excused for doing it (and I'll refrain from american bashing on this latter 
point...)

- The #8212 article that Tim mentions (out of its context) applies to the 'main()' function, not to Py_Main(), 
therefore the article #8212 does not apply to this case.

Sorry...

FG


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

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

Message:
Logged In: YES 
user_id=31435

The C standard doesn't support your claim.  Here from C99,
section 5.1.2.2.1 (Program startup):

"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""

You may not *like* programs to change them, but given that 
the std explicitly allows it you're fighting the universe 
(that is, it's you who are relying on non-standard 
behavior, not Python).

Assigned to Guido for Pronouncement.


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

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


From noreply@sourceforge.net  Thu May 10 18:17:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 10:17:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-416480 ] weakref needs better test suite
Message-ID: <E14xu4M-0005Nw-00@usw-sf-web3.sourceforge.net>

Bugs item #416480, was updated on 2001-04-16 10:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416480&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: weakref needs better test suite

Initial Comment:
The Weak*Dictionary classes need a more complete test suite.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-10 10:17

Message:
Logged In: YES 
user_id=3066

Added coverage for the complete mapping interface for both weakref.Weak*Dictionary classes in Lib/test/test_weakref.py revision 1.9.


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

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


From noreply@sourceforge.net  Thu May 10 18:23:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 10:23:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-423087 ] A small typo in weakref documentation
Message-ID: <E14xuAI-0005SZ-00@usw-sf-web3.sourceforge.net>

Bugs item #423087, was updated on 2001-05-10 09:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423087&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Yakov Markovitch (markovitch)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: A small typo in weakref documentation

Initial Comment:
In the description of weakref.proxy() there is written: 
"callable is the same as the parameter of the same name
to the ref() function."
There must be obviously "callback" instead of "callable".

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-10 10:23

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libweakref.tex revisions 1.8 and 1.7.2.1.

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

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


From noreply@sourceforge.net  Thu May 10 19:37:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 11:37:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-422088 ] [OSF1 alpha] string.replace()
Message-ID: <E14xvJj-0006P0-00@usw-sf-web3.sourceforge.net>

Bugs item #422088, was updated on 2001-05-07 11:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422088&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Martin Casado (martin_casado)
Assigned to: Tim Peters (tim_one)
Summary: [OSF1 alpha] string.replace()

Initial Comment:
>>> import sys
>>> sys.version
'2.0c1 (#7, Jan 24 2001, 15:36:12) [C]'
>>> s = "123"
>>> s.replace("123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError
>>> os.uname()
('OSF1', 'xxx', 'V4.0', '1229', 'alpha')
>>> 


I haven't tried it with anything newer, perhaps this
bug
has already been posted and/or fixed, though I couldn't
find it in the buglist

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-10 11:37

Message:
Logged In: YES 
user_id=6656

doh! i'd only updated stringobject.c.

sorry for being a doofus.  it all works now.

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

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

Message:
Logged In: YES 
user_id=31435

Ah!  No, I do NOT expect that.  The copies of mymemreplace
() in stringobject.c and stropmodule.c were (eventually) 
both replaced, and that was the source of the MemoryError.  
Did you have up-to-date versions of both?  If so, this is 
some other bug!  The only occurrence of PyMem_MALLOC() in 
stropmodule.c "got fixed".

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-10 03:45

Message:
Logged In: YES 
user_id=6656

I meant:

Python 2.2a0 (#3, May 10 2001, 07:57:08) [C] on osf1V4
Type "copyright", "credits" or "license" for more information.
>>> import strop
>>> strop.replace("123","123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

as I said, I thought this was expected, but thought I'd check (I 
did put a comment in yesterday that explained what I meant more
thouroughly, but sf ate it).


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 02:02

Message:
Logged In: YES 
user_id=31435

Sorry, don't know what "doesn't fix strop" means.  What's 
broken in strop?  The test case didn't use strop (although 
I mentioned stropmodule.c in a comment).  Closing the bug 
assuming this is some misunderstanding that's not worth the 
time to straighten out <0.7 wink>; please re-open if you 
think it is.

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-10 00:11

Message:
Logged In: YES 
user_id=6656

yep, fixes it.  doesn't fix strop, but I think that's
deliberate?

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 16:01

Message:
Logged In: YES 
user_id=31435

Good eye, Michael!  I've checked in what I hope will be a 
fix:

Lib/test/string_tests.py new revision: 1.8
Modules/stropmodule.c new revision: 2.77

Please give that a try and let me know whether it fixes the 
problem on this box.


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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 07:51

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 00:34

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 19:58

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try recompiling with optimization 
turned off.  If that makes the problem go away (seems 
likely to me), it's a platform compiler bug.

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

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


From noreply@sourceforge.net  Thu May 10 20:03:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 12:03:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-422088 ] [OSF1 alpha] string.replace()
Message-ID: <E14xvj2-0000SY-00@usw-sf-web1.sourceforge.net>

Bugs item #422088, was updated on 2001-05-07 11:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422088&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Martin Casado (martin_casado)
Assigned to: Tim Peters (tim_one)
Summary: [OSF1 alpha] string.replace()

Initial Comment:
>>> import sys
>>> sys.version
'2.0c1 (#7, Jan 24 2001, 15:36:12) [C]'
>>> s = "123"
>>> s.replace("123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError
>>> os.uname()
('OSF1', 'xxx', 'V4.0', '1229', 'alpha')
>>> 


I haven't tried it with anything newer, perhaps this
bug
has already been posted and/or fixed, though I couldn't
find it in the buglist

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

>Comment By: Martin Casado (martin_casado)
Date: 2001-05-10 12:03

Message:
Logged In: YES 
user_id=133423

I made the suggested changes and things are now working
grand! thanks guys.

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-10 11:37

Message:
Logged In: YES 
user_id=6656

doh! i'd only updated stringobject.c.

sorry for being a doofus.  it all works now.

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

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

Message:
Logged In: YES 
user_id=31435

Ah!  No, I do NOT expect that.  The copies of mymemreplace
() in stringobject.c and stropmodule.c were (eventually) 
both replaced, and that was the source of the MemoryError.  
Did you have up-to-date versions of both?  If so, this is 
some other bug!  The only occurrence of PyMem_MALLOC() in 
stropmodule.c "got fixed".

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-10 03:45

Message:
Logged In: YES 
user_id=6656

I meant:

Python 2.2a0 (#3, May 10 2001, 07:57:08) [C] on osf1V4
Type "copyright", "credits" or "license" for more information.
>>> import strop
>>> strop.replace("123","123","")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
MemoryError

as I said, I thought this was expected, but thought I'd check (I 
did put a comment in yesterday that explained what I meant more
thouroughly, but sf ate it).


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 02:02

Message:
Logged In: YES 
user_id=31435

Sorry, don't know what "doesn't fix strop" means.  What's 
broken in strop?  The test case didn't use strop (although 
I mentioned stropmodule.c in a comment).  Closing the bug 
assuming this is some misunderstanding that's not worth the 
time to straighten out <0.7 wink>; please re-open if you 
think it is.

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-10 00:11

Message:
Logged In: YES 
user_id=6656

yep, fixes it.  doesn't fix strop, but I think that's
deliberate?

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 16:01

Message:
Logged In: YES 
user_id=31435

Good eye, Michael!  I've checked in what I hope will be a 
fix:

Lib/test/string_tests.py new revision: 1.8
Modules/stropmodule.c new revision: 2.77

Please give that a try and let me know whether it fixes the 
problem on this box.


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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 07:51

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Michael Hudson (mwh)
Date: 2001-05-08 00:34

Message:
Logged In: YES 
user_id=6656

FWIW, I can (a) reproduce this on alpha/OSF1 (recompiling
stringobject.c without optimizations makes no odds,
recompiling all of Python takes too long on this particular
alpha) (b) make it go away by replacing the call to
PyMem_MALLOC in mymemreplace with one to PyMem_Malloc.

The difference is that PyMem_Malloc(0) can't be NULL;
PyMem_MALLOC can.

So either do this, or check if new_len is zero and return
PyString_FromString("") or something (in mymemreplace).

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 19:58

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try recompiling with optimization 
turned off.  If that makes the problem go away (seems 
likely to me), it's a platform compiler bug.

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

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


From noreply@sourceforge.net  Thu May 10 20:16:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 12:16:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-422678 ] argv is modified in Py_Main()
Message-ID: <E14xvv6-0000gh-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Guido van Rossum (gvanrossum)
Summary: argv is modified in Py_Main()

Initial Comment:
Context: Python 2.1 release

In function Py_Main( argc, argv), @[file main.c, line 287], argv is modified: 		
'argv[_PyOS_optind] = "-c";'

argv[] should remain constant, and should not be modified; I am getting a coredump when cleaning 
up the contents of argv[] in the calling process...

If you feel you need to modify argv[]; a copy of the array should be made at the beginning of 
Py_Main(), and then work/modify the copy; not the original !!!

Meanwhile, I'll pass a copy of argv to Py_Main(), and will clean up the original!!

FG


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

>Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 12:16

Message:
Logged In: YES 
user_id=93657

Tim,

If I summarize your argument in common words, it resumes to:
- I pollute the outside environment (the caller)
- this sh*t does not bother my live space, and it does not cost me a dime
- not emitting this sh*t would cost something to me, however little (3 basic instructions executed once: 1 
malloc, 1 memcpy, and 1 free); so I say it's going to 'bloat' my code and slow my start up
- keep up and deal with my sh*t
- anyway, there's hardly anybody out there besides you.

I guess all discussion is over on this.

FG


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 10:16

Message:
Logged In: YES 
user_id=31435

Frederic, the meaning of the std is plain:  if you modify a 
value, you store into it, so the last modification is the 
one that must stick "until program termination".  They're 
simply trying to forbid the environment from sticking argv 
in a volatile memory area (which some poor-quality C 
implementations have done in the past).

Note too that if the std *intended* argv to be read-only, 
they would have decorated its declaration with a "const" 
qualifier.  They did not.

The reason I *object* to making Py_Main more expensive is 
that its overwhelmingly most common uses are the calls from 
python.c and WinMain.c, direcly called from their 
respective C main() functions.  In a decade of using 
Python, the copying you want would never have bought me a 
thing, other than code bloat and extra expense on Python 
startup.  You've got the oddball use case here, so you're 
the one who should pay for it.


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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:47

Message:
Logged In: YES 
user_id=93657

I think Tim and I might even have misread article #8212.

In effect, having a second read at it:
"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""
The article actually states two things:
1) argv may be modified during execution of main()
2) argv MUST be restored to its initial value upon exit/termination.

So, in spite of all attempts at pursuing ambiguity, article #8212 states that when main() returns, argv must 
have been restored to its initial state/value.

FG




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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:38

Message:
Logged In: YES 
user_id=93657

There are three ways to consider Tim's answer:

- I know of general law of the universe of programming (something that goes beyond the C programming 
world, and above whatever standardization committee); that says something like 
"memory ownership of the parameters will belong either to the callee or the caller, and this ownership will 
not be modified by the callee".

- It is not because a 'local jurisdiction' allows to do a stupid thing (i.e. locally modifying arrays passed by a 
caller) that one is compelled or excused for doing it (and I'll refrain from american bashing on this latter 
point...)

- The #8212 article that Tim mentions (out of its context) applies to the 'main()' function, not to Py_Main(), 
therefore the article #8212 does not apply to this case.

Sorry...

FG


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

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

Message:
Logged In: YES 
user_id=31435

The C standard doesn't support your claim.  Here from C99,
section 5.1.2.2.1 (Program startup):

"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""

You may not *like* programs to change them, but given that 
the std explicitly allows it you're fighting the universe 
(that is, it's you who are relying on non-standard 
behavior, not Python).

Assigned to Guido for Pronouncement.


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

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


From noreply@sourceforge.net  Thu May 10 20:34:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 12:34:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-422678 ] argv is modified in Py_Main()
Message-ID: <E14xwCt-0007CO-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Guido van Rossum (gvanrossum)
Summary: argv is modified in Py_Main()

Initial Comment:
Context: Python 2.1 release

In function Py_Main( argc, argv), @[file main.c, line 287], argv is modified: 		
'argv[_PyOS_optind] = "-c";'

argv[] should remain constant, and should not be modified; I am getting a coredump when cleaning 
up the contents of argv[] in the calling process...

If you feel you need to modify argv[]; a copy of the array should be made at the beginning of 
Py_Main(), and then work/modify the copy; not the original !!!

Meanwhile, I'll pass a copy of argv to Py_Main(), and will clean up the original!!

FG


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-10 12:34

Message:
Logged In: YES 
user_id=6380

Frederic, this has turned into a pointless flamefest. 
Py_Main() isn't documented, and its argument is not declared
const, so I don't know why you assume that it shouldn't
modify its arguments. Since it does modify its arguments,
and has always done so, that assumption is wrong.

If this were becoming a common problem, I would consider
changing it, but you haven't explained in which context this
problem occurs; I have to assume that it's your specific use
that's causing the problem.

So I'm closing this bug report as "won't fix".

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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 12:16

Message:
Logged In: YES 
user_id=93657

Tim,

If I summarize your argument in common words, it resumes to:
- I pollute the outside environment (the caller)
- this sh*t does not bother my live space, and it does not cost me a dime
- not emitting this sh*t would cost something to me, however little (3 basic instructions executed once: 1 
malloc, 1 memcpy, and 1 free); so I say it's going to 'bloat' my code and slow my start up
- keep up and deal with my sh*t
- anyway, there's hardly anybody out there besides you.

I guess all discussion is over on this.

FG


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 10:16

Message:
Logged In: YES 
user_id=31435

Frederic, the meaning of the std is plain:  if you modify a 
value, you store into it, so the last modification is the 
one that must stick "until program termination".  They're 
simply trying to forbid the environment from sticking argv 
in a volatile memory area (which some poor-quality C 
implementations have done in the past).

Note too that if the std *intended* argv to be read-only, 
they would have decorated its declaration with a "const" 
qualifier.  They did not.

The reason I *object* to making Py_Main more expensive is 
that its overwhelmingly most common uses are the calls from 
python.c and WinMain.c, direcly called from their 
respective C main() functions.  In a decade of using 
Python, the copying you want would never have bought me a 
thing, other than code bloat and extra expense on Python 
startup.  You've got the oddball use case here, so you're 
the one who should pay for it.


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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:47

Message:
Logged In: YES 
user_id=93657

I think Tim and I might even have misread article #8212.

In effect, having a second read at it:
"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""
The article actually states two things:
1) argv may be modified during execution of main()
2) argv MUST be restored to its initial value upon exit/termination.

So, in spite of all attempts at pursuing ambiguity, article #8212 states that when main() returns, argv must 
have been restored to its initial state/value.

FG




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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:38

Message:
Logged In: YES 
user_id=93657

There are three ways to consider Tim's answer:

- I know of general law of the universe of programming (something that goes beyond the C programming 
world, and above whatever standardization committee); that says something like 
"memory ownership of the parameters will belong either to the callee or the caller, and this ownership will 
not be modified by the callee".

- It is not because a 'local jurisdiction' allows to do a stupid thing (i.e. locally modifying arrays passed by a 
caller) that one is compelled or excused for doing it (and I'll refrain from american bashing on this latter 
point...)

- The #8212 article that Tim mentions (out of its context) applies to the 'main()' function, not to Py_Main(), 
therefore the article #8212 does not apply to this case.

Sorry...

FG


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

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

Message:
Logged In: YES 
user_id=31435

The C standard doesn't support your claim.  Here from C99,
section 5.1.2.2.1 (Program startup):

"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""

You may not *like* programs to change them, but given that 
the std explicitly allows it you're fighting the universe 
(that is, it's you who are relying on non-standard 
behavior, not Python).

Assigned to Guido for Pronouncement.


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

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


From noreply@sourceforge.net  Thu May 10 21:39:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 13:39:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-423157 ] Python 2.1 Idle does not run on Win98
Message-ID: <E14xxDH-00084c-00@usw-sf-web3.sourceforge.net>

Bugs item #423157, was updated on 2001-05-10 13:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423157&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 Idle does not run on Win98

Initial Comment:
After downloading and running Python2-1.exe to install 
Python 2.1 on Windows 98 we are finding that the Idle 
application does not appear to run at all.

Clicking on Idle causes the hourglass to come up 
momentarily and then -- nothing.

Any ideas as to what is wrong?

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

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


From noreply@sourceforge.net  Thu May 10 22:36:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 10 May 2001 14:36:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-422339 ] 1 test failed: test_format
Message-ID: <E14xy6m-0002y4-00@usw-sf-web1.sourceforge.net>

Bugs item #422339, was updated on 2001-05-08 08:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422339&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
>Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: 1 test failed: test_format

Initial Comment:
Hallo!

OS:

OSF1 alpha04.faidor.de V4.0 1530 alpha

# cc -V
cc  (cc)
        Digital UNIX Compiler Driver 3.11
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)


Compiling and testing:

**********************************************************************
test_format
**********************************************************************
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == 
'00' != '0'", expected: ''


Version Python-2.1

Remark:

I found this error three times in the year 2000,
but resolved and for other Platforms

Kind regards
Hermann


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-10 14:36

Message:
Logged In: YES 
user_id=3066

This is entirely an issue of the platform libraries; the compiler is not an issue here.  You libraries are not compliant with the ANSI C specification, and Python does require ANSI C.

You should file a bug report with Compaq to get the C libraries fixed.


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 02:17

Message:
Logged In: YES 
user_id=31435

Hermann, for someone who doesn't use C, you're doing great!

Alas, I don't use gcc, so I'm at a dead end.  I've assigned 
the bug to Fred Drake and reopened it.  It's 5am where I 
live and I need to go to sleep.  Fred will be up in a few 
hours, and I hope he can take a look at this then.  Python 
runs and passes this test on *many* platforms that use gcc, 
so there's still something very odd here.  Fred, have a 
guess?  I tried it under Cygwin gcc, and the little C 
program prints "0" as expected (gcc version 2.95.3-4) -- 
but glibc is more relevant.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:59

Message:
Logged In: NO 

Hallo!

Sorry, I program Fortran and IDL, 
but I am not familiar with C.
But I can run it:

In both cases 
cc test.c
gcc test.c 

it prints out 
"00"
 
(gcc test.c
test.c: In function `main':
test.c:3: warning: return type of `main' is not `int')

Hermann



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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 01:46

Message:
Logged In: YES 
user_id=31435

I don't have access to this platform, so can't tell you.  
Did you try running the little C program I mentioned?

#include <stdio.h>
void main() {
printf("%#o\n", 0);
}

Does that print "0" or "00"?  If it prints "00", there's 
little we can do about it.  If it prints "0", we may have a 
problem (or may not; e.g., if you didn't start over from 
scratch, it's possible that you're picking up the old 
executable by mistake).

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:30

Message:
Logged In: NO 

Hello!

Now I tried with gcc 
and the same error appears. Why?

./configure --prefix=/opt_prog/local --with-gcc
gmake 
gmake test
-------
Then ...
We expected (repr): ''
But instead we got: "'%#o' % 0 == '00' != '0'"
test test_format failed -- Writing: "'%#o' % 0 == '00' != 
'0'", expected: ''
--------


and the whole thing is compiled with gcc.(2.95.3)

Hermann


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 01:29

Message:
Logged In: YES 
user_id=31435

Sorry, I see nothing surprising about Python using whatever 
cc resolves to by default on the system.  If you don't want 
C programs to use cc, change cc.

If you want it to use gcc on this platform instead, you 
should open a different bug report, or, better, supply a 
patch to the Unix config process:  the chance that any 
active Python developer uses this particular plaform is 
approximately 0, so that's also the chance that anyone can 
write and test a config change for you.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-09 01:10

Message:
Logged In: NO 

Hermann.Rochholz@gmx.de

Hello!

But why doesn't python use the gcc?
It's installed and every program I've translated before 
uses it automatiocally.

Regards
Hermann



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

Comment By: Tim Peters (tim_one)
Date: 2001-05-08 18:12

Message:
Logged In: YES 
user_id=31435

The Compaq compiler is in violation of the C std if it 
produces "00" for printf("%#o", 0), and all Python does 
here under the covers is call the platform sprintf.

Sometimes we put ugly stuff inside Python to worm around 
platform C bugs, but in this case the Compaq compiler is 
the only known offender.  Not worth it.  If

printf("%#o", 0)

does produce two zeroes in a C program using this compiler, 
file a bug with them.  Does it?  I'm closing this as "won't 
fix" assuming it does.


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

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


From noreply@sourceforge.net  Fri May 11 16:45:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 08:45:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-423157 ] Python 2.1 Idle does not run on Win98
Message-ID: <E14yF6s-0005HX-00@usw-sf-web3.sourceforge.net>

Bugs item #423157, was updated on 2001-05-10 13:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423157&group_id=5470

Category: IDLE
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: Python 2.1 Idle does not run on Win98

Initial Comment:
After downloading and running Python2-1.exe to install 
Python 2.1 on Windows 98 we are finding that the Idle 
application does not appear to run at all.

Clicking on Idle causes the hourglass to come up 
momentarily and then -- nothing.

Any ideas as to what is wrong?

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

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


From noreply@sourceforge.net  Fri May 11 16:50:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 08:50:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-420601 ] --with-next-framework very broken on OSX
Message-ID: <E14yFBw-0005NG-00@usw-sf-web3.sourceforge.net>

Bugs item #420601, was updated on 2001-05-01 18:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420601&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
>Assigned to: Jack Jansen (jackjansen)
Summary: --with-next-framework very broken on OSX

Initial Comment:
This bug report is not going to have a lot of useful 
data;  mostly just to get it into the system to see if 
others may care (or already be working on it).

In any case, --with-next-frameworks is quite broken 
under OSX.   It may not even really be pertinent any 
longer, but I have yet to verify that [investigation 
commences soon].

- executes ranlib against the dylib which breaks on 
OSX

- doesn't actually build a framework at all, but 
installs a dynamically loadable library (which may 
actually be more appropriate, all things 
considered)

- fails to install the dylib or any of the other .so 
modules in the actual platform specific directory 
where one might expect.  Instead, they end up in 
the generic dylib directory, but the PYTHONPATH 
does not search that directory.

- python executable will not launch because the 
dylib cannot be found.   However, given that the 
python executable does not have any kind of path 
information for the dylib, I'm not sure it would find it 
even if the dylib were installed in a "more correct" 
place.

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

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


From noreply@sourceforge.net  Fri May 11 16:50:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 08:50:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-422203 ] math.sqrt() broken on parisc-linux
Message-ID: <E14yFBH-0005Mi-00@usw-sf-web3.sourceforge.net>

Bugs item #422203, was updated on 2001-05-07 22:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422203&group_id=5470

Category: Extension Modules
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: dann frazier (dannf)
>Assigned to: Tim Peters (tim_one)
Summary: math.sqrt() broken on parisc-linux

Initial Comment:
python 2.0
Debian GNU/Linux on PA-RISC
package: python2-base_2.0-7

for any integer x, math.sqrt(x.0) seems to equal 0.0

----
sebadoh:/tmp# python2
Python 2.0 (#0, Apr 27 2001, 03:16:35) 
[GCC 3.0 20010315 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import math
>>> math.sqrt(2.0)
0.0
>>> math.sqrt(2)
1.4142135623730951
----

the C equivalent (math.h) reports the correct answer.

sebadoh:/tmp# uname -a
Linux sebadoh 2.4.0 #1 Mon May 7 12:41:27 MDT 2001
parisc unknown


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

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

Message:
Logged In: YES 
user_id=31435

Try recompiling with optimization off?  Python is written 
in C, and calls the same libm sqrt function you call when 
you write a C program.  It's very straightforward.  Nobody 
else has reported this problem, so there's something unique 
about your platform, and a buggy compiler is always the 
first guess when that occurs.

Also try a current version of Python (2.1 is current; 2.0 
is no longer supported officially, although a volunteer may 
produce a bugfix release for it).


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

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


From noreply@sourceforge.net  Fri May 11 17:37:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 09:37:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-417418 ] Python 2.1 compile error on HPUX
Message-ID: <E14yFue-0004W3-00@usw-sf-web1.sourceforge.net>

Bugs item #417418, was updated on 2001-04-19 11:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Richard Townsend (rptownsend)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Python 2.1 compile error on HPUX

Initial Comment:
Compiling Python2.1 on HPUX11.0 gives the following 
errors:

cc: "Modules/termios.c", line 529: error 
1588: "VREPRINT" undefined.
cc: "Modules/termios.c", line 529: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 530: error 
1588: "VDISCARD" undefined.
cc: "Modules/termios.c", line 530: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 747: error 1588: "MDCD" 
undefined.
cc: "Modules/termios.c", line 747: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 750: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 753: error 1588: "MCTS" 
undefined.
cc: "Modules/termios.c", line 753: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 756: error 1588: "MDSR" 
undefined.
cc: "Modules/termios.c", line 756: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 759: error 1588: "MDTR" 
undefined.
cc: "Modules/termios.c", line 759: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 765: error 1588: "MRI" 
undefined.
cc: "Modules/termios.c", line 765: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 768: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 771: error 1588: "MRTS" 
undefined.
cc: "Modules/termios.c", line 771: error 1521: 
Incorrect initialization.


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

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

Message:
Logged In: YES 
user_id=3066

I can't test on HP-UX, but have checked in the fix to both
the development and maintenance branches of Python.  If
someone using HP-UX could test Python from the CVS
repository (either branch) and report back, I'd appreciate it.

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

Comment By: The Written Word (china) (tww-china)
Date: 2001-05-06 22:29

Message:
Logged In: YES 
user_id=119770

You can find a fix for this at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-417418.patch

You'll need to rerurn autoheader and autoconf before
testing.

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

Comment By: Martin Jost (jost)
Date: 2001-05-04 01:55

Message:
Logged In: YES 
user_id=211439

The ones about M... (MCTS, MDTR, ...) are caused by the 
fact, that 
#include <sys/modem.h>
is needed for these on HPUX (10.20 at least) but not 
included.

But I found no fix for the V...-symbols


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-26 09:25

Message:
Logged In: NO 

The build also failes with HPUX B.10.20 A

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

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


From noreply@sourceforge.net  Fri May 11 17:38:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 09:38:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-417212 ] curses.newwin can return pads
Message-ID: <E14yFwK-0004Yb-00@usw-sf-web1.sourceforge.net>

Bugs item #417212, was updated on 2001-04-18 19:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417212&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David M. Cooke (dmcooke)
>Assigned to: A.M. Kuchling (akuchling)
Summary: curses.newwin can return pads

Initial Comment:
In 2.1 (at least), curses.newwin can return a pad
object if it's called with two arguments, i.e.

win = curses.newwin(0,0)

Since this is actually a pad, win.refresh has to be
called with six arguments -- the syntax used for
refreshing a pad -- instead of as just win.refresh()

Looking at the code for _cursesmodule.c, it appears
that only win.refresh() and win.noutrefresh() take
different arguments depending on whether win is
actually a window or a pad.

It looks like there are three options here: 

- document that the two-argument version of
curses.newwin returns a pad (and hence the six-argument
.refresh() must be used)

- make curses.newwin take four arguments only (as the
two argument version is currently equivalent to newpad)

- have win.refresh() and win.noutrefresh() do sensible
things for pads (although I don't know what that would
be...)

I would think #2 is the best.

Hmm, perhaps there should be a separate object type for
pads, so we can tell the difference between pads and
windows.

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

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


From noreply@sourceforge.net  Fri May 11 17:40:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 09:40:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-420476 ] Python 2.1 'make test' failures: AIX 4.2
Message-ID: <E14yFxZ-0004aZ-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: Python 2.1 'make test' failures: AIX 4.2

Initial Comment:
Successfully built and installed Python 2.1 on AIX 
4.2.  However, 3 regression tests failed.  The output 
from 'make test' (edited for brevity) is shown below:

make test
...successful tests deleted...
test___all__
test test___all__ failed -- tty has no __all__ 
attribute
...successful tests deleted...
test_coercion
The actual stdout doesn't match the expected stdout.
This much did match (between asterisk lines):
*******************************************************
***************
test_coercion
2 + 2 = 4
2 += 2 => 4
2 - 2 = 0
2 -= 2 => 0
2 * 2 = 4
2 *= 2 => 4
2 / 2 = 1
2 /= 2 => 1
2 ** 2 = 4
2 **= 2 => 4
2 % 2 = 0
2 %= 2 => 0
2 + 4.0 = 6.0
2 += 4.0 => 6.0
2 - 4.0 = -2.0
2 -= 4.0 => -2.0
2 * 4.0 = 8.0
2 *= 4.0 => 8.0
2 / 4.0 = 0.5
2 /= 4.0 => 0.5
2 ** 4.0 = 16.0
2 **= 4.0 => 16.0
2 % 4.0 = 2.0
2 %= 4.0 => 2.0
2 + 2 = 4
2 += 2 => 4
2 - 2 = 0
2 -= 2 => 0
2 * 2 = 4
2 *= 2 => 4
2 / 2 = 1
2 /= 2 => 1
2 ** 2 = 4
2 **= 2 => 4
2 % 2 = 0
2 %= 2 => 0
2 + (2+0j) = (4+0j)
2 += (2+0j) => (4+0j)
2 - (2+0j) = 0j
2 -= (2+0j) => 0j
2 * (2+0j) = (4+0j)
2 *= (2+0j) => (4+0j)
2 / (2+0j) =
*******************************************************
***************
Then ...
We expected (repr): '(1+0j)'
But instead we got: '(1-0j)'
test test_coercion failed -- Writing: '(1-0j)', 
expected: '(1+0j)'
...successful tests deleted...
test_pty
test test_pty failed -- Tail of expected stdout 
unseen: 'y pet fish, Eric.\n'
...successful tests deleted...
test_zlib
test test_zlib skipped --  No module named zlib
112 tests OK.
3 tests failed: test___all__ test_coercion test_pty
22 tests skipped: test_al test_bsddb test_cd test_cl 
test_dl test_gdbm test_gl test_gzip test_imgfile 
test_largefile test_linuxaudio
dev test_minidom test_nis test_openpty test_pyexpat 
test_sax test_sunaudiodev test_sundry test_winreg 
test_winsound test_zipfile test_zlib
make: 1254-004 The error code from the last command is 
1.


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

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


From noreply@sourceforge.net  Fri May 11 17:41:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 09:41:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-417587 ] compiler warnings compiling 2.1
Message-ID: <E14yFz7-0004bw-00@usw-sf-web1.sourceforge.net>

Bugs item #417587, was updated on 2001-04-20 02:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417587&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Sjoerd Mullender (sjoerd)
>Assigned to: Sjoerd Mullender (sjoerd)
Summary: compiler warnings compiling 2.1

Initial Comment:
I get a whole bunch of compiler warnings when compiling 
the stock Python-2.1 on SGI IRIX 6.5.11m.  These 
warnings are innocuous, but I feel that many of them 
should be fixed anyway.  I particularly dislike code 
where a goto or return is immediately followed by 
break.  There is just *no way* the flow of control can 
get to that break and I feel that it betrays 
uncertainty in the programmer.

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

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

Message:
Logged In: YES 
user_id=3066

Sjoerd, are you planning to follow up on this?  See Tim's
remarks.

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

Comment By: Tim Peters (tim_one)
Date: 2001-04-20 19:47

Message:
Logged In: YES 
user_id=31435

Sjoerd, it would be much more helpful if you submitted a 
patch.  We don't have an SGI IRIX 6.5.11m box to compile 
on, so can't tell whether we've fixed anything.  We have 
a "no compiler warnings!" policy that I enforce under the 
Windows build, and so I don't see *any* warnings in the 2.1 
build.

I fixed the most egregious ones where fixes were obviously 
harmless, checked in as

mmapmodule.c new revision: 2.28
unicodeobject.c new revision: 2.86
tokenizer.c new revision: 2.50
ceval.c new revision: 2.240


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

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


From noreply@sourceforge.net  Fri May 11 17:45:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 09:45:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-417472 ] Unneccessary warning message
Message-ID: <E14yG2r-0004gb-00@usw-sf-web1.sourceforge.net>

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

>Category: Distutils
Group: Not a Bug
Status: Open
Resolution: None
>Priority: 2
Submitted By: Viktor Ferenczi (complex)
>Assigned to: Greg Ward (gward)
Summary: Unneccessary warning message

Initial Comment:
Unneccessary warning message near to the end of Python
2.1 compilation:

warning: install: modules installed to
'/usr/local/lib/python2.1/lib-dynload/',
which is not in Python's module search path (sys.path)
-- you'll have to change
the search path yourself

The search path contains the
/usr/local/lib/python2.1/lib-dynload directory,
so this warning message is not required.

System: RedHat Linux 7.0 (Kernel 2.2.17, gcc 2.96)

- Complex -

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

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

Message:
Logged In: YES 
user_id=3066

This appears to be a distutils-generated message, so I'm
assigning this to the distutils guru.

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

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


From noreply@sourceforge.net  Fri May 11 19:27:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 11:27:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-420476 ] Python 2.1 'make test' failures: AIX 4.2
Message-ID: <E14yHdP-000176-00@usw-sf-web2.sourceforge.net>

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

Category: None
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: Python 2.1 'make test' failures: AIX 4.2

Initial Comment:
Successfully built and installed Python 2.1 on AIX 
4.2.  However, 3 regression tests failed.  The output 
from 'make test' (edited for brevity) is shown below:

make test
...successful tests deleted...
test___all__
test test___all__ failed -- tty has no __all__ 
attribute
...successful tests deleted...
test_coercion
The actual stdout doesn't match the expected stdout.
This much did match (between asterisk lines):
*******************************************************
***************
test_coercion
2 + 2 = 4
2 += 2 => 4
2 - 2 = 0
2 -= 2 => 0
2 * 2 = 4
2 *= 2 => 4
2 / 2 = 1
2 /= 2 => 1
2 ** 2 = 4
2 **= 2 => 4
2 % 2 = 0
2 %= 2 => 0
2 + 4.0 = 6.0
2 += 4.0 => 6.0
2 - 4.0 = -2.0
2 -= 4.0 => -2.0
2 * 4.0 = 8.0
2 *= 4.0 => 8.0
2 / 4.0 = 0.5
2 /= 4.0 => 0.5
2 ** 4.0 = 16.0
2 **= 4.0 => 16.0
2 % 4.0 = 2.0
2 %= 4.0 => 2.0
2 + 2 = 4
2 += 2 => 4
2 - 2 = 0
2 -= 2 => 0
2 * 2 = 4
2 *= 2 => 4
2 / 2 = 1
2 /= 2 => 1
2 ** 2 = 4
2 **= 2 => 4
2 % 2 = 0
2 %= 2 => 0
2 + (2+0j) = (4+0j)
2 += (2+0j) => (4+0j)
2 - (2+0j) = 0j
2 -= (2+0j) => 0j
2 * (2+0j) = (4+0j)
2 *= (2+0j) => (4+0j)
2 / (2+0j) =
*******************************************************
***************
Then ...
We expected (repr): '(1+0j)'
But instead we got: '(1-0j)'
test test_coercion failed -- Writing: '(1-0j)', 
expected: '(1+0j)'
...successful tests deleted...
test_pty
test test_pty failed -- Tail of expected stdout 
unseen: 'y pet fish, Eric.\n'
...successful tests deleted...
test_zlib
test test_zlib skipped --  No module named zlib
112 tests OK.
3 tests failed: test___all__ test_coercion test_pty
22 tests skipped: test_al test_bsddb test_cd test_cl 
test_dl test_gdbm test_gl test_gzip test_imgfile 
test_largefile test_linuxaudio
dev test_minidom test_nis test_openpty test_pyexpat 
test_sax test_sunaudiodev test_sundry test_winreg 
test_winsound test_zipfile test_zlib
make: 1254-004 The error code from the last command is 
1.


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

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

Message:
Logged In: YES 
user_id=31435

test___all__ failures are always spurious (due to 
incomplete module objects left behind in sys.modules for 
other reasons -- in this case presumably related to the 
test_pty failure).

The test_coerce failure is a +0 versus -0 IEEE-754 thing.  
Platforms that produce -0 here are not computing the 
correct sign bit for (+0)-(+0) (according to the 754 
rules).  First make sure you're using whatever gibberish 
your platform C requires to produce 754-conforming code.  
If it still fails, and the HW supports any sort of fused 
multiply+add or multiply+subtract instructions, tell the 
compiler not to use them.  If it still fails, we're in for 
long and tedious platform-specific debugging work.

Assigned to Barry in case he has a clue about test_pty (I 
don't).

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

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


From noreply@sourceforge.net  Fri May 11 20:40:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 12:40:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E14yIm6-0001yT-00@usw-sf-web2.sourceforge.net>

Bugs item #411881, was updated on 2001-03-28 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


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

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

Message:
Logged In: YES 
user_id=3066

OK, I've fixed up a few more modules:

anydbm
chunk
formatter
htmllib
mailcap
pre
pty

I made one change to asyncore as well, but other bare except
clauses remain there; I'm not sufficiently familiar with
that code to just go digging into those.

I also fixed an infraction in pstats, but left others for now.

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

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

Message:
Logged In: YES 
user_id=31435

Ping's intent is that pydoc work under versions of Python 
as early as 1.5.2, so that sys._getframe is off-limits in 
pydoc and its supporting code (like inspect.py).

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-23 00:32

Message:
Logged In: YES 
user_id=21627

For inspect.py, why is it necessary to keep the old code at
all? My proposal: remove currentframe altogether, and do
currentframe = sys._getframe
unconditionally.

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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-22 07:52

Message:
Logged In: YES 
user_id=32065

I submitted a 4th patch. I'm starting to run out of easy
cases...

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-04-19 02:15

Message:
Logged In: YES 
user_id=44345

I believe the following patch is correct for the try/except
in inspect.currentframe.  Note that it fixes two problems. 
One, it avoids a bare except.  Two, it gets rid of a string
argument to the raise statement (string exceptions are now
deprecated, right?).

*** /tmp/skip/inspect.py	Thu Apr 19 04:13:36 2001
--- /tmp/skip/inspect.py.~1.16~	Thu Apr 19 04:13:36 2001
***************
*** 643,650 ****
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         1/0
!     except ZeroDivisionError:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe
--- 643,650 ----
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         raise 'catch me'
!     except:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe


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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-17 08:27

Message:
Logged In: YES 
user_id=32065

inspect.py uses sys_getframe if it's there, the other code
is for backwards compatibility.

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

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

Message:
Logged In: YES 
user_id=6380

Actually, inspect.py should use sys._getframe()!

And yes, KeyboardError is definitely one of the reasons why
this is such a bad idiom...

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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


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

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 10:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


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

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

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 02:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

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

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-29 22:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

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

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


From noreply@sourceforge.net  Fri May 11 21:00:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 13:00:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-423157 ] Python 2.1 Idle does not run on Win98
Message-ID: <E14yJ5k-0002Ck-00@usw-sf-web2.sourceforge.net>

Bugs item #423157, was updated on 2001-05-10 13:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423157&group_id=5470

Category: IDLE
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: Python 2.1 Idle does not run on Win98

Initial Comment:
After downloading and running Python2-1.exe to install 
Python 2.1 on Windows 98 we are finding that the Idle 
application does not appear to run at all.

Clicking on Idle causes the hourglass to come up 
momentarily and then -- nothing.

Any ideas as to what is wrong?

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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-11 13:00

Message:
Logged In: YES 
user_id=31435

I run IDLE under 2.1 on Win98 every day.  No problem.

>From where did you obtain Python?  "Python2-1.exe" isn't a 
file name I recognize, so I don't know, for example, 
whether you got 2.1 from python.org, or ActiveState, or 
etc.  You certainly didn't get a file named Python2-1.exe 
from python.org.  The distributions differ in some 
respects, so we can't make any progress here without more 
info from you.

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

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


From noreply@sourceforge.net  Fri May 11 21:03:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 13:03:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-420771 ] 'rw' option to open: is it a bug?
Message-ID: <E14yJ8N-0002EX-00@usw-sf-web2.sourceforge.net>

Bugs item #420771, was updated on 2001-05-02 10:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420771&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'rw' option to open: is it a bug?

Initial Comment:
if you open a file with 'rw'

f = open('foo.bar','rw')
ie you will be able to read, but not write

Python 2.1 (#3, Apr 19 2001, 11:45:56) [C] on sunos5
Type "copyright", "credits" or "license" for more
information.
>>> f = open("foo.bar",'rw')
>>> f.read()
'HelloWorld\n'
>>> f.write("NotWhatIExpect")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file number
>>> 

However the rw does not seem to be a valid option, yet
no error is produced upon opening the file, rather
when the operation is attempted.

It seems that what is needed if you want
'rw' is 'r+'.

>>> f = open("foo.bar",'r+')
>>> f.read() 
'HelloWorld\n'
>>> f.write("ThisIsWhatIExpect")
>>> f.close()

Could therefore 'rw' signal an error? Or do the
same as 'r+'?

  

 

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

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

Message:
Logged In: YES 
user_id=3066

Tim's right.  There's no good reason to change this so long
as we rely on the platforms standard I/O libraries, so I'm
closing this as "Won't Fix".  It can be reasonably argued
that this is a bug, but in the platform libraries, not Python.

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

Comment By: Tim Peters (tim_one)
Date: 2001-05-02 10:57

Message:
Logged In: YES 
user_id=31435

Python doesn't look at the mode argument:  it passes it on 
as-is to the platform C fopen() function.  This allows 
people to use whatever non-standard modes their platform 
supports.  An error is reported if and only if the platform 
fopen() sets errno across the call.

Mode "rw" isn't defined by C ("r+" and "w+" are), so 
whether a platform accepts it is up to the platform; and, 
if it does accept it, what it means is also up to the 
platform.  So that "rw" was accepted when you tried it 
means that sunos5's fopen() accepts an "rw" mode.  You'll 
have to consult Sun's docs for whether it's working as they 
intended it to work.

Could be useful if Python warned about non-standard modes.

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

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


From noreply@sourceforge.net  Fri May 11 21:06:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 13:06:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-417491 ] UnixWare BUILD *STILL* uses ld -G
Message-ID: <E14yJB9-0002GQ-00@usw-sf-web2.sourceforge.net>

Bugs item #417491, was updated on 2001-04-19 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417491&group_id=5470

>Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Rosenman (ler)
>Assigned to: Neil Schemenauer (nascheme)
Summary: UnixWare BUILD *STILL* uses ld -G

Initial Comment:
bug 231439 is BACK in the 2.1 final release.  It still
uses ld -G. 

ALL shared objects, ESPECIALLY those using threads,
should be compiled  *AND* linked using cc -G. 

I'm very disappointed in that the bug was closed but
the QA process dropped the fix(es). 


ALSO, when doing the initial build using Shared
Objects, you need to set -R and/or set LD_LIBRARY_PATH
to suit. 



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

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 19:55

Message:
Logged In: YES 
user_id=36452

Oh, and I'm VERY willing to test RC's. I didn't realize it
was close to release.....



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

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 19:35

Message:
Logged In: YES 
user_id=36452

Ok. Sorry for the screaming, but the CVS sources are STILL
broken.

Can someone look at the patch I generated, and see if it can
be integrated 
into current CVS? 

I've built 2.1 with it on UnixWare 7 7.1.1 with the UDK FS
7.1.1b compiler. 

It works. 



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

Comment By: Tim Peters (tim_one)
Date: 2001-04-21 19:30

Message:
Logged In: YES 
user_id=31435

LARRY, there's REALLY no need to SCREAM on *EACH* word in 
THREE <wink>.

You're not impressed by QA -- join the club.  Testing is 
done by volunteers, and if there are no volunteers *trying* 
the release candidates on a new platform, we have no way to 
know whether they work.  Linux and Windows and Mac Classic 
are pretty well covered by volunteers, but that's about 
it.  If UnixWare is important enough to you, volunteer to 
test release candidates there yourself, or even pay someone 
to do it.  But don't go honking on Martin!  That's out of 
line.

About your "The last comments on this patch are telling.", 
the last comments on that patch were made *after* the 
release.  Before the release, Guido checked in the patch 
that the UnixWare user said was needed.  He can't guess 
whether a patch actually works on a platform he doesn't 
use.  The last patch comment by a UnixWare user *before* 
the release reads

"""Every thing looks fine (as far as I can tell)."""

WRT "why the H*LL didn't the release .tar get RE-ROLLED?", 
it's because nobody said anything was broken until after 
the release shipped (your bug report here was 2 days after 
the release).

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

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 17:34

Message:
Logged In: YES 
user_id=36452

OK, here is a patch I wrote to configure.in to fix this. 
regen configure and config.h.in 

Let me know if this is acceptable.  THis is against the
2.1-RELEASE version. 

Larry 

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

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:45

Message:
Logged In: YES 
user_id=36452

Oh, and 1.215 is *BROKE*, as it spec's ld -G, not CC -G,
around line 615 or so.

PLEASE fix. 

PLEASE generate a FIX RELEASE for the 2.1 RELEASE.

This is *NOT* a good sign that a broken PORT didn't stop the
release process. 



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

Comment By: Larry Rosenman (ler)
Date: 2001-04-21 15:23

Message:
Logged In: YES 
user_id=36452

OK, why the H*LL didn't the release .tar get RE-ROLLED?  The
last comments on this patch are telling.  

I'm *NOT* impressed, and the bug reported here is mentioned
in that stream, so why wasn't the RELEASE held for this? 
the port is PROMINENTLY mentioned in the release notes, but
it's BROKE in the RELEASE.  How can I get a new tarball from
y'all? 



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

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-21 05:55

Message:
Logged In: YES 
user_id=21627

I agree this is very unfortunate. Please have a look at
patch 413011, which was committed as 1.215 of configure.in.

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

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


From noreply@sourceforge.net  Fri May 11 21:03:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 13:03:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-422203 ] math.sqrt() broken on parisc-linux
Message-ID: <E14yJ7t-0002EN-00@usw-sf-web2.sourceforge.net>

Bugs item #422203, was updated on 2001-05-07 22:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422203&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: dann frazier (dannf)
Assigned to: Tim Peters (tim_one)
Summary: math.sqrt() broken on parisc-linux

Initial Comment:
python 2.0
Debian GNU/Linux on PA-RISC
package: python2-base_2.0-7

for any integer x, math.sqrt(x.0) seems to equal 0.0

----
sebadoh:/tmp# python2
Python 2.0 (#0, Apr 27 2001, 03:16:35) 
[GCC 3.0 20010315 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import math
>>> math.sqrt(2.0)
0.0
>>> math.sqrt(2)
1.4142135623730951
----

the C equivalent (math.h) reports the correct answer.

sebadoh:/tmp# uname -a
Linux sebadoh 2.4.0 #1 Mon May 7 12:41:27 MDT 2001
parisc unknown


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

>Comment By: Tim Peters (tim_one)
Date: 2001-05-11 13:03

Message:
Logged In: YES 
user_id=31435

If we don't get more info here soon, I'm going to just 
close this.

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

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

Message:
Logged In: YES 
user_id=31435

Try recompiling with optimization off?  Python is written 
in C, and calls the same libm sqrt function you call when 
you write a C program.  It's very straightforward.  Nobody 
else has reported this problem, so there's something unique 
about your platform, and a buggy compiler is always the 
first guess when that occurs.

Also try a current version of Python (2.1 is current; 2.0 
is no longer supported officially, although a volunteer may 
produce a bugfix release for it).


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

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


From noreply@sourceforge.net  Fri May 11 21:29:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 13:29:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-423429 ] very minor nit in library ref
Message-ID: <E14yJXK-000098-00@usw-sf-web1.sourceforge.net>

Bugs item #423429, was updated on 2001-05-11 13:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423429&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michel Pelletier (michel)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: very minor nit in library ref

Initial Comment:
http://www.python.org/doc/current/ref/types.html

says "Python distinguishes between integers and
floating point numbers:"

but then goes on to list integer, floating point, and
complex numbers.  It should mention complex numbers in
that sentence.

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

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


From noreply@sourceforge.net  Fri May 11 22:28:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 14:28:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-416943 ] 2.1 segfaults on pydoc HTTP
Message-ID: <E14yKT4-0001BE-00@usw-sf-web1.sourceforge.net>

Bugs item #416943, was updated on 2001-04-17 20:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416943&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Andy Dustman (adustman)
Assigned to: Ka-Ping Yee (ping)
Summary: 2.1 segfaults on pydoc HTTP 

Initial Comment:
Platform info: 2.1 final, Red Hat 7.1 beta for i386.

Run pydoc -p xxx. Pull up info on a C extension module.
Now
recompile that module so that it changes in a
significant way.
Try to pull it up again and segfault occurs.

#0  0x0808db62 in PyString_FromString (str=0x0) at
Objects/stringobject.c:89
84	}
85	
86	PyObject *
87	PyString_FromString(const char *str)
88	{
89		register size_t size = strlen(str);
90		register PyStringObject *op;
91		if (size > INT_MAX) {
92			PyErr_SetString(PyExc_OverflowError,
93				"string is too long for a Python string");
(gdb) frame 1
#1  0x0808d003 in PyObject_GetAttrString (v=0x8164ec0, 
    name=0x80c888c "__name__") at Objects/object.c:1002
1002			return (*v->ob_type->tp_getattr)(v, name);
(gdb) list
997				     v->ob_type->tp_name,
998				     name);
999			return NULL;
1000		}
1001		else {
1002			return (*v->ob_type->tp_getattr)(v, name);
1003		}
1004	}
1005	
1006	int
(gdb) print (*v->ob_type->tp_getattr)
$1 = {PyObject *()} 0x808b3c8 <meth_getattr>
$6 = {ob_refcnt = 3, ob_type = 0x80bb920, ob_size = 0, 
  tp_name = 0x80aa94e "builtin_function_or_method",
tp_basicsize = 16, 
  tp_itemsize = 0, tp_dealloc = 0x808b390
<meth_dealloc>, tp_print = 0, 
  tp_getattr = 0x808b3c8 <meth_getattr>, tp_setattr =
0, 
  tp_compare = 0x808b550 <meth_compare>, tp_repr =
0x808b4ec <meth_repr>, 
  tp_as_number = 0x0, tp_as_sequence = 0x0,
tp_as_mapping = 0x0, 
  tp_hash = 0x808b5a4 <meth_hash>, tp_call = 0, tp_str
= 0, tp_getattro = 0, 
  tp_setattro = 0, tp_as_buffer = 0x0, tp_flags = 0,
tp_doc = 0x0, 
  tp_traverse = 0, tp_clear = 0, tp_richcompare = 0,
tp_weaklistoffset = 0}
(gdb) print ((PyCFunctionObject *)v)->m_ml
$7 = (PyMethodDef *) 0x401c7ecc
(gdb) print
$8 = 0x0
(gdb) list meth_getattr
67		free_list = m;
68	}
69	
70	static PyObject *
71	meth_getattr(PyCFunctionObject *m, char *name)
72	{
73		if (strcmp(name, "__name__") == 0) {
74			return PyString_FromString(m->m_ml->ml_name);
75		}
76		if (strcmp(name, "__doc__") == 0) {

((PyCFunctionObject *)v)->m_ml->ml_name ==
m->m_ml->ml_name == NULL. From what I can tell, all
members of v->m_ml are NULL. Note that name is getting
smashed somewhere, probably after the call at
Objects/object.c:1002.

Feel free to contact me for further information if
necessary. Complete backtrace attached.

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

>Comment By: Andy Dustman (adustman)
Date: 2001-05-11 14:28

Message:
Logged In: YES 
user_id=71372

I know what the problem is now. I was reinstalling packages
using Distutils, and when Distutils copies files, it
overwrites any existing file. Needless to say, when it
overwrites a dynamic library, bad things happen, if
something is using it.

Suggested solution: Distutils should write to a temporary
file and then rename this to the final destination name. On
UNIX, the original file will be unlinked, but not deleted
until the last reader closes it. Not sure about other
platforms, or how hard filename restrictions will make this.

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

Comment By: Andy Dustman (adustman)
Date: 2001-04-26 12:05

Message:
Logged In: YES 
user_id=71372

...and just to clarify, I don't think this is a pydoc bug.
It seems to be related to Python internals. The module used
in this case is MySQLdb
(http://sourceforge.net/projects/mysql-python). It could be
related to that module, but I really don't think so.

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

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


From noreply@sourceforge.net  Sat May 12 00:15:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 16:15:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-417472 ] Unneccessary warning message
Message-ID: <E14yM7j-000356-00@usw-sf-web1.sourceforge.net>

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

Category: Distutils
Group: Not a Bug
Status: Open
Resolution: None
Priority: 2
Submitted By: Viktor Ferenczi (complex)
Assigned to: Greg Ward (gward)
Summary: Unneccessary warning message

Initial Comment:
Unneccessary warning message near to the end of Python
2.1 compilation:

warning: install: modules installed to
'/usr/local/lib/python2.1/lib-dynload/',
which is not in Python's module search path (sys.path)
-- you'll have to change
the search path yourself

The search path contains the
/usr/local/lib/python2.1/lib-dynload directory,
so this warning message is not required.

System: RedHat Linux 7.0 (Kernel 2.2.17, gcc 2.96)

- Complex -

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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-11 16:15

Message:
Logged In: YES 
user_id=149084

Duplicate of Bug 232619....

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 09:45

Message:
Logged In: YES 
user_id=3066

This appears to be a distutils-generated message, so I'm
assigning this to the distutils guru.

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

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


From noreply@sourceforge.net  Sat May 12 01:20:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 11 May 2001 17:20:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-423472 ] Hang in select.select() and time.sleep()
Message-ID: <E14yN9X-00050C-00@usw-sf-web2.sourceforge.net>

Bugs item #423472, was updated on 2001-05-11 17:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423472&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Seguin (rpseguin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hang in select.select() and time.sleep()

Initial Comment:
Platform:  FreeBSD 4.0
Python version:   2.0 and 2.1  (maybe 1.5.2, haven't
tried)

There is a bug in the select() code that manifests
itself as a hang of the process if the system clock is
adjusted during a call to  select.select() or
time.sleep()  (which uses select())

I'm guessing that this might be related to the
reentrant., thread-safe libc_r.so used by the Python
runtime.


Steps to reproduce:

rseguin% python
Python 2.1 (#1, May 11 2001, 16:54:06)
[GCC 2.95 19990728 (release)] on freebsd4
Type "copyright", "credits" or "license" for more
information.
>>> import time
>>>
time.sleep(10.0)                                                            
(now set the system clock date/time via another shell)

Result is one of two things:
-ether  time.sleep()  (or select.select()) never comes
back
-OR it comes back after the time delta from previous
time before clock adjust and the adjusted time + the
desired sleep time interval.

This bug is more insidious than it may initially seem,
as there are any of a number of time adjusting daemons
(xntpd, ntpd, ...).  This is a nasty bug for daemon
style code in particular, as the daemon appears to be
running, while it is actually just hung.

This bug was in 2.0 and it is still there in 2.1

-Ralph
rpseguin@yahoo.com




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

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


From noreply@sourceforge.net  Sat May 12 21:37:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 12 May 2001 13:37:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-420601 ] --with-next-framework very broken on OSX
Message-ID: <E14yg8M-0006Au-00@usw-sf-web1.sourceforge.net>

Bugs item #420601, was updated on 2001-05-01 18:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420601&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Jack Jansen (jackjansen)
Summary: --with-next-framework very broken on OSX

Initial Comment:
This bug report is not going to have a lot of useful 
data;  mostly just to get it into the system to see if 
others may care (or already be working on it).

In any case, --with-next-frameworks is quite broken 
under OSX.   It may not even really be pertinent any 
longer, but I have yet to verify that [investigation 
commences soon].

- executes ranlib against the dylib which breaks on 
OSX

- doesn't actually build a framework at all, but 
installs a dynamically loadable library (which may 
actually be more appropriate, all things 
considered)

- fails to install the dylib or any of the other .so 
modules in the actual platform specific directory 
where one might expect.  Instead, they end up in 
the generic dylib directory, but the PYTHONPATH 
does not search that directory.

- python executable will not launch because the 
dylib cannot be found.   However, given that the 
python executable does not have any kind of path 
information for the dylib, I'm not sure it would find it 
even if the dylib were installed in a "more correct" 
place.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2001-05-12 13:37

Message:
Logged In: YES 
user_id=45365

I know next-to-nothing of OSX frameworks yet, so I asked Steve Majewski <sdm7g@Virginia.EDU>,
and he came up with the following bit. Any more insights are welcome.

Steve said:
 It's definitely badly broken for OSX, and my suggestion was (and is)
to make (eventually) building a framework a separate post-build step
with it's own script. I'm not sure if anything different has to be
done during the build as prep or not. I'm guessing not -- I think on
OSX it's mainly going to be a question of packaging -- sort of how
you bundle up the resources, etc. into MacPython. 
 I think the only question about ripping it out is whether it's needed
for Next or OpenStep  support and is anyone still using it? ( There 
REALLY ARE folks who are still using them, and occasionally complain
on *.advocacy that it's still better than OSX, etc. but do any of them
use Python? ) 

 What is the policy ? 

 If it's that if no one on python-dev wants to speak up and adopt a 
platform, out it goes -- then by all means, dump it. (Although you
might want to put out an "official" Last Call first.)  

 Has this come up before ? Is there a PEP ? 
 If not, maybe we should write up a "last call for platform savior" 
 process proposal.  

 I know there's a PEP on removing features -- I'll have to look at
it and see if it covers platforms. I do prefer having a policy 
(whatever it is) than doing it ad.hoc. for basically the same reasons
as having one on feature removal. 


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

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


From noreply@sourceforge.net  Sat May 12 22:18:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 12 May 2001 14:18:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E14ygmI-0000WT-00@usw-sf-web2.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



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

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-12 14:18

Message:
Logged In: YES 
user_id=198402

Another solution could be to modify the behaviour of the 
server so that it would be the responsibility of 
the "child" thread/process to close the socket (except for 
the forking/threading error cases). Wouldn't it be simplier 
than child process tracking and thread tracking?

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-04 04:17

Message:
Logged In: YES 
user_id=80200

okay.  the forkingmixin code does a fork, records how many
children there are, and waits for one of them to exit,
before
proceeding - in particular, before proceeding to close
the request, etc.

... so why is not something similar done in ThreadingMixIn?

this kinda- tells me that thread-tracking is really needed,
in a similar way to that in forkingmixin.

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

Comment By: Gregory P. Smith (greg)
Date: 2001-05-03 16:26

Message:
Logged In: YES 
user_id=413

Just a note of another casualty of this bug: I had to add
the mentioned dummy close_request method hack to our own
ThreadingMixIn class in mojo nation (in the sourceforge
mojonation project's evil module, see the
common/MojoNationHTTPServer.py file).  Without it, python
2.1 would always raise an exception in the request handler
as soon as it tried to call self.connection.makefile()
because self.connection had apparently already been closed! 
(its fd was always -1)


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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-02 01:41

Message:
Logged In: YES 
user_id=80200

hi there mr jrielh,

thank you very much for the details.  what i am having a
little difficulty with is, what's the difference between
this and python 2.0 SocketServer.py?

more specifically, i'm looking at python 2.0 SocketServer.py
and, whilst i'm not a Threads expert, i see a t.start() but
no t.join().  i've been looking at the Queue example code in
the test method of threads.py, and start() is called on
every thread, followed by join() on every thread.  join
waits for the thread to finish, yes?

so... if that's the case, then python 2.0 SocketServer.py
should suffer from
exactly the same behaviour, yes?  unless python behaves
ever-so-slightly differently (timing issues?) when you have
an extra base class like this,
with the consequence that close_request() is more likely to
be called
before ThreadingMixIn.process_request().

?

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

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:20

Message:
Logged In: YES 
user_id=22448

This is related to bug #419873.
The problem is not specifically in the ThreadingMixin
specifically, but where BaseServer calls close_request()
after calling process_request().  In the threading mixin,
process_request() spins the thread and returns, causing the
request socket to be invalidated while the thread is still
running.  The fix given above will keep the socket valid
while the thread is running, but may cause the socket to not
close properly (my threads generally close the socket when
they are done anyway.)

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

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

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


From noreply@sourceforge.net  Sat May 12 22:53:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 12 May 2001 14:53:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-422678 ] argv is modified in Py_Main()
Message-ID: <E14yhKS-0007QU-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Guido van Rossum (gvanrossum)
Summary: argv is modified in Py_Main()

Initial Comment:
Context: Python 2.1 release

In function Py_Main( argc, argv), @[file main.c, line 287], argv is modified: 		
'argv[_PyOS_optind] = "-c";'

argv[] should remain constant, and should not be modified; I am getting a coredump when cleaning 
up the contents of argv[] in the calling process...

If you feel you need to modify argv[]; a copy of the array should be made at the beginning of 
Py_Main(), and then work/modify the copy; not the original !!!

Meanwhile, I'll pass a copy of argv to Py_Main(), and will clean up the original!!

FG


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

>Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-12 14:53

Message:
Logged In: YES 
user_id=93657

Guido,

The calling context is pasted below (from Javapy.c, 2de beta release). It is in the context of the 
Java-Python Extension.
This will permit using 'java python.PyRun' as a substitute to the 'python' command for the situations where 
the Java shared library (libjvm.so) cannot be open by dlopen() (for unknown reasons so far, on some 
platforms; e.g. Linux); while preserving the same option and environment variable semantics.

'char const* const* argv' is calculated from a 'void main( String[] argv)' Java class method...

JNIEXPORT jint JNICALL Java_python_Javapy_Py_1Main ( JNIEnv* env,
						     jclass self, 
						     jobjectArray jargv)
{
  .... calculation of argv from jargv ....
  {
    /* Py_Main modifies its argv array argument (mis-behaved function...),
     * therefore a copy of argv must be passed.
     * See Python bug report 422678
     */
    char const** argv_copy;
    size_t argvsz;
    argvsz = argc * (sizeof *argv_copy);
    argv_copy = (char const**)malloc( argvsz);
    (void)memcpy( (void*)argv_copy, (void*)argv, argvsz);
    LogTrace;
    result = (jint)Py_Main( argc, argv_copy);
    LogTrace;
    free( (void*)argv_copy);
  }

 EXIT:
  for (idx = 0; idx < argc; idx++) jutil_UTF_cleanup( env, argv + idx);
  free( (void*)argv);
  LogTrace;

  return result;
}

On one end, I'm reluctant to rewrite the options processing code for JPE; on the other end, Py_Main() works 
right out of the box, minus the memory problem (I'll let you figure out the time & work it took me to track 
this down...). 

And yes, that is right that Py_Main() is not published, just like PyThread_GetDict() is not published either (I 
think these are the only 2 unpublished Python functions used in JPE, so it's a pretty good score).

You know, I as do, that 'const' is missused in 90% of the situations (e.g. 'const char*' vs. 'char const*'...); 
but this is not the issue in my perspective; and that strings in C is a particularly hairy issue, and that C 
const and pointer definitions mix together just like oil and vinegar.

The question is the respect of memory owernship rules between caller and callee, without regard to the 
function signature [const/not const] (not to mention standardization legislation), and without derogation; 
this something that is vital in C/C++ programming, and whose violation is responsible for most of the C/C++ 
program instablilities

This is a recurrent problem whenever strings are present (be they defined as char*, char const*, const 
char*, char [], const char [], char const [], or passed as array like in argv, the array being or not 
constant....).

FG



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-10 12:34

Message:
Logged In: YES 
user_id=6380

Frederic, this has turned into a pointless flamefest. 
Py_Main() isn't documented, and its argument is not declared
const, so I don't know why you assume that it shouldn't
modify its arguments. Since it does modify its arguments,
and has always done so, that assumption is wrong.

If this were becoming a common problem, I would consider
changing it, but you haven't explained in which context this
problem occurs; I have to assume that it's your specific use
that's causing the problem.

So I'm closing this bug report as "won't fix".

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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 12:16

Message:
Logged In: YES 
user_id=93657

Tim,

If I summarize your argument in common words, it resumes to:
- I pollute the outside environment (the caller)
- this sh*t does not bother my live space, and it does not cost me a dime
- not emitting this sh*t would cost something to me, however little (3 basic instructions executed once: 1 
malloc, 1 memcpy, and 1 free); so I say it's going to 'bloat' my code and slow my start up
- keep up and deal with my sh*t
- anyway, there's hardly anybody out there besides you.

I guess all discussion is over on this.

FG


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

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 10:16

Message:
Logged In: YES 
user_id=31435

Frederic, the meaning of the std is plain:  if you modify a 
value, you store into it, so the last modification is the 
one that must stick "until program termination".  They're 
simply trying to forbid the environment from sticking argv 
in a volatile memory area (which some poor-quality C 
implementations have done in the past).

Note too that if the std *intended* argv to be read-only, 
they would have decorated its declaration with a "const" 
qualifier.  They did not.

The reason I *object* to making Py_Main more expensive is 
that its overwhelmingly most common uses are the calls from 
python.c and WinMain.c, direcly called from their 
respective C main() functions.  In a decade of using 
Python, the copying you want would never have bought me a 
thing, other than code bloat and extra expense on Python 
startup.  You've got the oddball use case here, so you're 
the one who should pay for it.


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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:47

Message:
Logged In: YES 
user_id=93657

I think Tim and I might even have misread article #8212.

In effect, having a second read at it:
"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""
The article actually states two things:
1) argv may be modified during execution of main()
2) argv MUST be restored to its initial value upon exit/termination.

So, in spite of all attempts at pursuing ambiguity, article #8212 states that when main() returns, argv must 
have been restored to its initial state/value.

FG




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

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:38

Message:
Logged In: YES 
user_id=93657

There are three ways to consider Tim's answer:

- I know of general law of the universe of programming (something that goes beyond the C programming 
world, and above whatever standardization committee); that says something like 
"memory ownership of the parameters will belong either to the callee or the caller, and this ownership will 
not be modified by the callee".

- It is not because a 'local jurisdiction' allows to do a stupid thing (i.e. locally modifying arrays passed by a 
caller) that one is compelled or excused for doing it (and I'll refrain from american bashing on this latter 
point...)

- The #8212 article that Tim mentions (out of its context) applies to the 'main()' function, not to Py_Main(), 
therefore the article #8212 does not apply to this case.

Sorry...

FG


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

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

Message:
Logged In: YES 
user_id=31435

The C standard doesn't support your claim.  Here from C99,
section 5.1.2.2.1 (Program startup):

"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""

You may not *like* programs to change them, but given that 
the std explicitly allows it you're fighting the universe 
(that is, it's you who are relying on non-standard 
behavior, not Python).

Assigned to Guido for Pronouncement.


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

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


From noreply@sourceforge.net  Sat May 12 23:46:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 12 May 2001 15:46:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E14yi9v-0008Lc-00@usw-sf-web1.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-12 15:46

Message:
Logged In: YES 
user_id=80200

hi there mr xlagraula,

yes, it would be a lot simpler... _if_ it wasn't
for the fact that this code is likely to already
be quite extensively used.  a possible 'upgrade'
path could be done by providing a... RequestHandler2
class, or some-such.

it would be neater to do this, or similar:
for t in self.thread_list:
    t.join(timeout=0.1)

which would join all threads, or you do if
stopped(), close_request.  i looked into
threads a bit more: join has a timeout,
and there is a stopped-detection function.

easy :)

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

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-12 14:18

Message:
Logged In: YES 
user_id=198402

Another solution could be to modify the behaviour of the 
server so that it would be the responsibility of 
the "child" thread/process to close the socket (except for 
the forking/threading error cases). Wouldn't it be simplier 
than child process tracking and thread tracking?

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-04 04:17

Message:
Logged In: YES 
user_id=80200

okay.  the forkingmixin code does a fork, records how many
children there are, and waits for one of them to exit,
before
proceeding - in particular, before proceeding to close
the request, etc.

... so why is not something similar done in ThreadingMixIn?

this kinda- tells me that thread-tracking is really needed,
in a similar way to that in forkingmixin.

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

Comment By: Gregory P. Smith (greg)
Date: 2001-05-03 16:26

Message:
Logged In: YES 
user_id=413

Just a note of another casualty of this bug: I had to add
the mentioned dummy close_request method hack to our own
ThreadingMixIn class in mojo nation (in the sourceforge
mojonation project's evil module, see the
common/MojoNationHTTPServer.py file).  Without it, python
2.1 would always raise an exception in the request handler
as soon as it tried to call self.connection.makefile()
because self.connection had apparently already been closed! 
(its fd was always -1)


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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-02 01:41

Message:
Logged In: YES 
user_id=80200

hi there mr jrielh,

thank you very much for the details.  what i am having a
little difficulty with is, what's the difference between
this and python 2.0 SocketServer.py?

more specifically, i'm looking at python 2.0 SocketServer.py
and, whilst i'm not a Threads expert, i see a t.start() but
no t.join().  i've been looking at the Queue example code in
the test method of threads.py, and start() is called on
every thread, followed by join() on every thread.  join
waits for the thread to finish, yes?

so... if that's the case, then python 2.0 SocketServer.py
should suffer from
exactly the same behaviour, yes?  unless python behaves
ever-so-slightly differently (timing issues?) when you have
an extra base class like this,
with the consequence that close_request() is more likely to
be called
before ThreadingMixIn.process_request().

?

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

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:20

Message:
Logged In: YES 
user_id=22448

This is related to bug #419873.
The problem is not specifically in the ThreadingMixin
specifically, but where BaseServer calls close_request()
after calling process_request().  In the threading mixin,
process_request() spins the thread and returns, causing the
request socket to be invalidated while the thread is still
running.  The fix given above will keep the socket valid
while the thread is running, but may cause the socket to not
close properly (my threads generally close the socket when
they are done anyway.)

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

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

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


From noreply@sourceforge.net  Sun May 13 15:40:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 07:40:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-423721 ] failure in urllib exception handling
Message-ID: <E14yx37-00075v-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Becker (rgbecker)
Assigned to: Nobody/Anonymous (nobody)
Summary: failure in urllib exception handling

Initial Comment:
This is observed sometimes using webchecker.py running python 2.0 under freeBSD 4.2
seems like urllib might checking strings against Exception instances

webchecker version 1.22

Round 1 (1 total, 1 to do, 0 done, 0 bad)


Round 2 (20 total, 19 to do, 1 done, 0 bad)


Round 3 (117 total, 97 to do, 20 done, 0 bad)


Saving checkpoint to @webchecker.pickle ...
Done.
Use ``/usr/local/lib/python2.0/Tools/webchecker/webchecker.py -R'' to
restart.
Traceback (most recent call last):
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
824, in ?
    main()
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
222, in main
    c.run()
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
349, in run
    self.dopage(url)
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
403, in dopage
    page = self.getpage(url_pair)
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
496, in getpage
    f = self.openpage(url_pair)
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
534, in openpage
    return self.urlopener.open(url)
  File "/usr/local/lib/python2.0/urllib.py", line 166, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.0/urllib.py", line 457, in open_ftp
    (fp, retrlen) = self.ftpcache[key].retrfile(file, type)
  File "/usr/local/lib/python2.0/urllib.py", line 692, in retrfile
    if reason[:3] != '550':
TypeError: sequence index must be integer

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

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


From noreply@sourceforge.net  Sun May 13 16:04:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 08:04:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-423728 ] improper value of sys.argv with '-c' opt
Message-ID: <E14yxPf-0007TE-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: improper value of sys.argv with '-c' opt

Initial Comment:

Python 2,1 gives the following result:

---
python -c "import sys; print sys.argv"
[ '-c']
---

This is uncorrect and error-prone.

The two (possible) correct answers are:
    [] # strip off the '-c' stuff
  or
    [ '-c', 'import sys; print sys.argv'] # keep the '-c' stuff

  but ['-c'] alone is definitely uncorrect, as well as it does not make sense.

The source of the problem can explicitly be traced to file Python-2.1 -main.c, line 287:
  argv[_PyOS_optind] = "-c"; 
        (cf. [ python-Bugs-422678 ] (argv is modified in Py_Main())

which modifies 'argv' as side effect; this then messes up the initialization of 'sys.argv'.

Note: This bug is another side effect of [ python-Bugs-422678 ]

FG


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

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


From noreply@sourceforge.net  Sun May 13 16:51:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 08:51:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E14yy9f-0003qt-00@usw-sf-web2.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



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

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-13 08:51

Message:
Logged In: YES 
user_id=198402

What I propose can be applied without any compatibility 
issue.

I have tried something that seems to work, at least under 
windows (but it does need to be more fully tested though). 
Only 2 small modifications are required:

-1- In BaseServer, modification of the last line of 
handle_request:
<PRE>
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)

</PRE>
Note that only the indentation of the last has been 
modified so that the close_request is executed only if an 
exception occur.

Still we need to close the request after it had been 
processed, so here comes the second modification:
-2- Still in BaseServer:
<PRE>
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
</PRE>

There is already a try/except block in handle_request, so I 
thought it was not mandatory here to ensure the request was 
always closed.

Oh... I don't know how &lt;PRE&gt; tags are supported by 
the bugtracking system of sourceforge, so the samples I 
give may not appear as I want. This is quite a problem with 
python :/

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-12 15:46

Message:
Logged In: YES 
user_id=80200

hi there mr xlagraula,

yes, it would be a lot simpler... _if_ it wasn't
for the fact that this code is likely to already
be quite extensively used.  a possible 'upgrade'
path could be done by providing a... RequestHandler2
class, or some-such.

it would be neater to do this, or similar:
for t in self.thread_list:
    t.join(timeout=0.1)

which would join all threads, or you do if
stopped(), close_request.  i looked into
threads a bit more: join has a timeout,
and there is a stopped-detection function.

easy :)

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

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-12 14:18

Message:
Logged In: YES 
user_id=198402

Another solution could be to modify the behaviour of the 
server so that it would be the responsibility of 
the "child" thread/process to close the socket (except for 
the forking/threading error cases). Wouldn't it be simplier 
than child process tracking and thread tracking?

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-04 04:17

Message:
Logged In: YES 
user_id=80200

okay.  the forkingmixin code does a fork, records how many
children there are, and waits for one of them to exit,
before
proceeding - in particular, before proceeding to close
the request, etc.

... so why is not something similar done in ThreadingMixIn?

this kinda- tells me that thread-tracking is really needed,
in a similar way to that in forkingmixin.

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

Comment By: Gregory P. Smith (greg)
Date: 2001-05-03 16:26

Message:
Logged In: YES 
user_id=413

Just a note of another casualty of this bug: I had to add
the mentioned dummy close_request method hack to our own
ThreadingMixIn class in mojo nation (in the sourceforge
mojonation project's evil module, see the
common/MojoNationHTTPServer.py file).  Without it, python
2.1 would always raise an exception in the request handler
as soon as it tried to call self.connection.makefile()
because self.connection had apparently already been closed! 
(its fd was always -1)


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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-02 01:41

Message:
Logged In: YES 
user_id=80200

hi there mr jrielh,

thank you very much for the details.  what i am having a
little difficulty with is, what's the difference between
this and python 2.0 SocketServer.py?

more specifically, i'm looking at python 2.0 SocketServer.py
and, whilst i'm not a Threads expert, i see a t.start() but
no t.join().  i've been looking at the Queue example code in
the test method of threads.py, and start() is called on
every thread, followed by join() on every thread.  join
waits for the thread to finish, yes?

so... if that's the case, then python 2.0 SocketServer.py
should suffer from
exactly the same behaviour, yes?  unless python behaves
ever-so-slightly differently (timing issues?) when you have
an extra base class like this,
with the consequence that close_request() is more likely to
be called
before ThreadingMixIn.process_request().

?

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

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:20

Message:
Logged In: YES 
user_id=22448

This is related to bug #419873.
The problem is not specifically in the ThreadingMixin
specifically, but where BaseServer calls close_request()
after calling process_request().  In the threading mixin,
process_request() spins the thread and returns, causing the
request socket to be invalidated while the thread is still
running.  The fix given above will keep the socket valid
while the thread is running, but may cause the socket to not
close properly (my threads generally close the socket when
they are done anyway.)

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470


From noreply@sourceforge.net  Sun May 13 17:05:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 09:05:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-422678 ] argv is modified in Py_Main()
Message-ID: <E14yyNW-000403-00@usw-sf-web2.sourceforge.net>

Bugs item #422678, was updated on 2001-05-09 08:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422678&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Guido van Rossum (gvanrossum)
Summary: argv is modified in Py_Main()

Initial Comment:
Context: Python 2.1 release

In function Py_Main( argc, argv), @[file main.c, line 287], argv is modified: 		
'argv[_PyOS_optind] = "-c";'

argv[] should remain constant, and should not be modified; I am getting a coredump when cleaning 
up the contents of argv[] in the calling process...

If you feel you need to modify argv[]; a copy of the array should be made at the beginning of 
Py_Main(), and then work/modify the copy; not the original !!!

Meanwhile, I'll pass a copy of argv to Py_Main(), and will clean up the original!!

FG


----------------------------------------------------------------------

>Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 09:05

Message:
Logged In: YES 
user_id=93657

Guido,

The calling context is pasted below (from Javapy.c, 2de beta release). It is in the context of the 
Java-Python Extension.
This will permit using 'java python.PyRun' as a substitute to the 'python' command for the situations where 
the Java shared library (libjvm.so) cannot be open by dlopen() (for unknown reasons so far, on some 
platforms; e.g. Linux); while preserving the same option and environment variable semantics.

'char const* const* argv' is calculated from a 'void main( String[] argv)' Java class method...

JNIEXPORT jint JNICALL Java_python_Javapy_Py_1Main ( JNIEnv* env,
						     jclass self, 
						     jobjectArray jargv)
{
  .... calculation of argv from jargv ....
  {
    /* Py_Main modifies its argv array argument (mis-behaved function...),
     * therefore a copy of argv must be passed.
     * See Python bug report 422678
     */
    char const** argv_copy;
    size_t argvsz;
    argvsz = argc * (sizeof *argv_copy);
    argv_copy = (char const**)malloc( argvsz);
    (void)memcpy( (void*)argv_copy, (void*)argv, argvsz);
    LogTrace;
    result = (jint)Py_Main( argc, argv_copy);
    LogTrace;
    free( (void*)argv_copy);
  }

 EXIT:
  for (idx = 0; idx < argc; idx++) jutil_UTF_cleanup( env, argv + idx);
  free( (void*)argv);
  LogTrace;

  return result;
}

On one end, I'm reluctant to rewrite the options processing code for JPE; on the other end, Py_Main() works 
right out of the box, minus the memory problem (I'll let you figure out the time & work it took me to track 
this down...). 

And yes, that is right that Py_Main() is not published, just like PyThread_GetDict() is not published either (I 
think these are the only 2 unpublished Python functions used in JPE, so it's a pretty good score).

You know, I as do, that 'const' is missused in 90% of the situations (e.g. 'const char*' vs. 'char const*'...); 
but this is not the issue in my perspective; and that strings in C is a particularly hairy issue, and that C 
const and pointer definitions mix together just like oil and vinegar.

The question is the respect of memory owernship rules between caller and callee, without regard to the 
function signature [const/not const] (not to mention standardization legislation), and without derogation; 
this something that is vital in C/C++ programming, and whose violation is responsible for most of the C/C++ 
program instablilities

This is a recurrent problem whenever strings are present (be they defined as char*, char const*, const 
char*, char [], const char [], char const [], or passed as array like in argv, the array being or not 
constant....).

FG



----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-12 14:53

Message:
Logged In: YES 
user_id=93657

Guido,

The calling context is pasted below (from Javapy.c, 2de beta release). It is in the context of the 
Java-Python Extension.
This will permit using 'java python.PyRun' as a substitute to the 'python' command for the situations where 
the Java shared library (libjvm.so) cannot be open by dlopen() (for unknown reasons so far, on some 
platforms; e.g. Linux); while preserving the same option and environment variable semantics.

'char const* const* argv' is calculated from a 'void main( String[] argv)' Java class method...

JNIEXPORT jint JNICALL Java_python_Javapy_Py_1Main ( JNIEnv* env,
						     jclass self, 
						     jobjectArray jargv)
{
  .... calculation of argv from jargv ....
  {
    /* Py_Main modifies its argv array argument (mis-behaved function...),
     * therefore a copy of argv must be passed.
     * See Python bug report 422678
     */
    char const** argv_copy;
    size_t argvsz;
    argvsz = argc * (sizeof *argv_copy);
    argv_copy = (char const**)malloc( argvsz);
    (void)memcpy( (void*)argv_copy, (void*)argv, argvsz);
    LogTrace;
    result = (jint)Py_Main( argc, argv_copy);
    LogTrace;
    free( (void*)argv_copy);
  }

 EXIT:
  for (idx = 0; idx < argc; idx++) jutil_UTF_cleanup( env, argv + idx);
  free( (void*)argv);
  LogTrace;

  return result;
}

On one end, I'm reluctant to rewrite the options processing code for JPE; on the other end, Py_Main() works 
right out of the box, minus the memory problem (I'll let you figure out the time & work it took me to track 
this down...). 

And yes, that is right that Py_Main() is not published, just like PyThread_GetDict() is not published either (I 
think these are the only 2 unpublished Python functions used in JPE, so it's a pretty good score).

You know, I as do, that 'const' is missused in 90% of the situations (e.g. 'const char*' vs. 'char const*'...); 
but this is not the issue in my perspective; and that strings in C is a particularly hairy issue, and that C 
const and pointer definitions mix together just like oil and vinegar.

The question is the respect of memory owernship rules between caller and callee, without regard to the 
function signature [const/not const] (not to mention standardization legislation), and without derogation; 
this something that is vital in C/C++ programming, and whose violation is responsible for most of the C/C++ 
program instablilities

This is a recurrent problem whenever strings are present (be they defined as char*, char const*, const 
char*, char [], const char [], char const [], or passed as array like in argv, the array being or not 
constant....).

FG



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-10 12:34

Message:
Logged In: YES 
user_id=6380

Frederic, this has turned into a pointless flamefest. 
Py_Main() isn't documented, and its argument is not declared
const, so I don't know why you assume that it shouldn't
modify its arguments. Since it does modify its arguments,
and has always done so, that assumption is wrong.

If this were becoming a common problem, I would consider
changing it, but you haven't explained in which context this
problem occurs; I have to assume that it's your specific use
that's causing the problem.

So I'm closing this bug report as "won't fix".

----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 12:16

Message:
Logged In: YES 
user_id=93657

Tim,

If I summarize your argument in common words, it resumes to:
- I pollute the outside environment (the caller)
- this sh*t does not bother my live space, and it does not cost me a dime
- not emitting this sh*t would cost something to me, however little (3 basic instructions executed once: 1 
malloc, 1 memcpy, and 1 free); so I say it's going to 'bloat' my code and slow my start up
- keep up and deal with my sh*t
- anyway, there's hardly anybody out there besides you.

I guess all discussion is over on this.

FG


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-10 10:16

Message:
Logged In: YES 
user_id=31435

Frederic, the meaning of the std is plain:  if you modify a 
value, you store into it, so the last modification is the 
one that must stick "until program termination".  They're 
simply trying to forbid the environment from sticking argv 
in a volatile memory area (which some poor-quality C 
implementations have done in the past).

Note too that if the std *intended* argv to be read-only, 
they would have decorated its declaration with a "const" 
qualifier.  They did not.

The reason I *object* to making Py_Main more expensive is 
that its overwhelmingly most common uses are the calls from 
python.c and WinMain.c, direcly called from their 
respective C main() functions.  In a decade of using 
Python, the copying you want would never have bought me a 
thing, other than code bloat and extra expense on Python 
startup.  You've got the oddball use case here, so you're 
the one who should pay for it.


----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:47

Message:
Logged In: YES 
user_id=93657

I think Tim and I might even have misread article #8212.

In effect, having a second read at it:
"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""
The article actually states two things:
1) argv may be modified during execution of main()
2) argv MUST be restored to its initial value upon exit/termination.

So, in spite of all attempts at pursuing ambiguity, article #8212 states that when main() returns, argv must 
have been restored to its initial state/value.

FG




----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-10 04:38

Message:
Logged In: YES 
user_id=93657

There are three ways to consider Tim's answer:

- I know of general law of the universe of programming (something that goes beyond the C programming 
world, and above whatever standardization committee); that says something like 
"memory ownership of the parameters will belong either to the callee or the caller, and this ownership will 
not be modified by the callee".

- It is not because a 'local jurisdiction' allows to do a stupid thing (i.e. locally modifying arrays passed by a 
caller) that one is compelled or excused for doing it (and I'll refrain from american bashing on this latter 
point...)

- The #8212 article that Tim mentions (out of its context) applies to the 'main()' function, not to Py_Main(), 
therefore the article #8212 does not apply to this case.

Sorry...

FG


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-09 13:19

Message:
Logged In: YES 
user_id=31435

The C standard doesn't support your claim.  Here from C99,
section 5.1.2.2.1 (Program startup):

"""
&#8212; The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program, and
retain their last-stored values between program startup and 
program termination.
"""

You may not *like* programs to change them, but given that 
the std explicitly allows it you're fighting the universe 
(that is, it's you who are relying on non-standard 
behavior, not Python).

Assigned to Guido for Pronouncement.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422678&group_id=5470


From noreply@sourceforge.net  Sun May 13 17:09:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 09:09:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E14yyR8-00006W-00@usw-sf-web1.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-13 09:09

Message:
Logged In: YES 
user_id=198402

I forgot to tell: I can not test if it does not break the 
forking server. I only have a windows platform available 
for now, and forking doesn't work in the python/win32 
environment for now as far as I know.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-13 08:51

Message:
Logged In: YES 
user_id=198402

What I propose can be applied without any compatibility 
issue.

I have tried something that seems to work, at least under 
windows (but it does need to be more fully tested though). 
Only 2 small modifications are required:

-1- In BaseServer, modification of the last line of 
handle_request:
<PRE>
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)

</PRE>
Note that only the indentation of the last has been 
modified so that the close_request is executed only if an 
exception occur.

Still we need to close the request after it had been 
processed, so here comes the second modification:
-2- Still in BaseServer:
<PRE>
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
</PRE>

There is already a try/except block in handle_request, so I 
thought it was not mandatory here to ensure the request was 
always closed.

Oh... I don't know how &lt;PRE&gt; tags are supported by 
the bugtracking system of sourceforge, so the samples I 
give may not appear as I want. This is quite a problem with 
python :/

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-12 15:46

Message:
Logged In: YES 
user_id=80200

hi there mr xlagraula,

yes, it would be a lot simpler... _if_ it wasn't
for the fact that this code is likely to already
be quite extensively used.  a possible 'upgrade'
path could be done by providing a... RequestHandler2
class, or some-such.

it would be neater to do this, or similar:
for t in self.thread_list:
    t.join(timeout=0.1)

which would join all threads, or you do if
stopped(), close_request.  i looked into
threads a bit more: join has a timeout,
and there is a stopped-detection function.

easy :)

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-12 14:18

Message:
Logged In: YES 
user_id=198402

Another solution could be to modify the behaviour of the 
server so that it would be the responsibility of 
the "child" thread/process to close the socket (except for 
the forking/threading error cases). Wouldn't it be simplier 
than child process tracking and thread tracking?

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-04 04:17

Message:
Logged In: YES 
user_id=80200

okay.  the forkingmixin code does a fork, records how many
children there are, and waits for one of them to exit,
before
proceeding - in particular, before proceeding to close
the request, etc.

... so why is not something similar done in ThreadingMixIn?

this kinda- tells me that thread-tracking is really needed,
in a similar way to that in forkingmixin.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2001-05-03 16:26

Message:
Logged In: YES 
user_id=413

Just a note of another casualty of this bug: I had to add
the mentioned dummy close_request method hack to our own
ThreadingMixIn class in mojo nation (in the sourceforge
mojonation project's evil module, see the
common/MojoNationHTTPServer.py file).  Without it, python
2.1 would always raise an exception in the request handler
as soon as it tried to call self.connection.makefile()
because self.connection had apparently already been closed! 
(its fd was always -1)


----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-02 01:41

Message:
Logged In: YES 
user_id=80200

hi there mr jrielh,

thank you very much for the details.  what i am having a
little difficulty with is, what's the difference between
this and python 2.0 SocketServer.py?

more specifically, i'm looking at python 2.0 SocketServer.py
and, whilst i'm not a Threads expert, i see a t.start() but
no t.join().  i've been looking at the Queue example code in
the test method of threads.py, and start() is called on
every thread, followed by join() on every thread.  join
waits for the thread to finish, yes?

so... if that's the case, then python 2.0 SocketServer.py
should suffer from
exactly the same behaviour, yes?  unless python behaves
ever-so-slightly differently (timing issues?) when you have
an extra base class like this,
with the consequence that close_request() is more likely to
be called
before ThreadingMixIn.process_request().

?

----------------------------------------------------------------------

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:20

Message:
Logged In: YES 
user_id=22448

This is related to bug #419873.
The problem is not specifically in the ThreadingMixin
specifically, but where BaseServer calls close_request()
after calling process_request().  In the threading mixin,
process_request() spins the thread and returns, causing the
request socket to be invalidated while the thread is still
running.  The fix given above will keep the socket valid
while the thread is running, but may cause the socket to not
close properly (my threads generally close the socket when
they are done anyway.)

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470


From noreply@sourceforge.net  Sun May 13 19:17:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 11:17:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-423728 ] improper value of sys.argv with '-c' opt
Message-ID: <E14z0QV-00077z-00@usw-sf-web3.sourceforge.net>

Bugs item #423728, was updated on 2001-05-13 08:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423728&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: improper value of sys.argv with '-c' opt

Initial Comment:

Python 2,1 gives the following result:

---
python -c "import sys; print sys.argv"
[ '-c']
---

This is uncorrect and error-prone.

The two (possible) correct answers are:
    [] # strip off the '-c' stuff
  or
    [ '-c', 'import sys; print sys.argv'] # keep the '-c' stuff

  but ['-c'] alone is definitely uncorrect, as well as it does not make sense.

The source of the problem can explicitly be traced to file Python-2.1 -main.c, line 287:
  argv[_PyOS_optind] = "-c"; 
        (cf. [ python-Bugs-422678 ] (argv is modified in Py_Main())

which modifies 'argv' as side effect; this then messes up the initialization of 'sys.argv'.

Note: This bug is another side effect of [ python-Bugs-422678 ]

FG


----------------------------------------------------------------------

>Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 11:17

Message:
Logged In: YES 
user_id=93657

Actually, I need to correct something.

When using 'python -c "some; cmd", the expected value for sys.argv would be either:
  [ ''] # sys.argv value in interactive mode -> sys.argv[ 0] == ''
or
  [ 'some; cmd'] # value of the '-c' option: -> sys.argv[ 0] == 'some; cmd' - this contains more information

In this case, lines 283-288 from main.c could just be deleted.

FG


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423728&group_id=5470


From noreply@sourceforge.net  Sun May 13 19:17:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 11:17:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-423728 ] improper value of sys.argv with '-c' opt
Message-ID: <E14z0Qt-0005Ph-00@usw-sf-web2.sourceforge.net>

Bugs item #423728, was updated on 2001-05-13 08:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423728&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: improper value of sys.argv with '-c' opt

Initial Comment:

Python 2,1 gives the following result:

---
python -c "import sys; print sys.argv"
[ '-c']
---

This is uncorrect and error-prone.

The two (possible) correct answers are:
    [] # strip off the '-c' stuff
  or
    [ '-c', 'import sys; print sys.argv'] # keep the '-c' stuff

  but ['-c'] alone is definitely uncorrect, as well as it does not make sense.

The source of the problem can explicitly be traced to file Python-2.1 -main.c, line 287:
  argv[_PyOS_optind] = "-c"; 
        (cf. [ python-Bugs-422678 ] (argv is modified in Py_Main())

which modifies 'argv' as side effect; this then messes up the initialization of 'sys.argv'.

Note: This bug is another side effect of [ python-Bugs-422678 ]

FG


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-13 11:17

Message:
Logged In: YES 
user_id=31435

Not a bug.  Note also, e.g.,

> python -c "import sys; print sys.argv" a b c
['-c', 'a', 'b', 'c']

See the docs for sys.argv (in the Library manual) -- this 
is the documented and intended behavior.  argv[0] is (as 
also in C) supposed to be the name of the script, but when 
the script is passed literally on the cmdline there is no 
sensible name.  "-c" is as good as anything then.  
*Something* name-like must be passed in argv[0] else code 
that examines sys.argv would have to know whether or not 
Python started via -c.

argv[1:] is supposed contain the arguments to the script.  
Since the expression following -c *is* the script, it would 
be incorrect to leave that in argv:  the script is not an 
argument to itself, after all.


----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 11:17

Message:
Logged In: YES 
user_id=93657

Actually, I need to correct something.

When using 'python -c "some; cmd", the expected value for sys.argv would be either:
  [ ''] # sys.argv value in interactive mode -> sys.argv[ 0] == ''
or
  [ 'some; cmd'] # value of the '-c' option: -> sys.argv[ 0] == 'some; cmd' - this contains more information

In this case, lines 283-288 from main.c could just be deleted.

FG


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423728&group_id=5470


From noreply@sourceforge.net  Sun May 13 19:27:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 11:27:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-423728 ] improper value of sys.argv with '-c' opt
Message-ID: <E14z0b1-0002J5-00@usw-sf-web1.sourceforge.net>

Bugs item #423728, was updated on 2001-05-13 08:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423728&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: improper value of sys.argv with '-c' opt

Initial Comment:

Python 2,1 gives the following result:

---
python -c "import sys; print sys.argv"
[ '-c']
---

This is uncorrect and error-prone.

The two (possible) correct answers are:
    [] # strip off the '-c' stuff
  or
    [ '-c', 'import sys; print sys.argv'] # keep the '-c' stuff

  but ['-c'] alone is definitely uncorrect, as well as it does not make sense.

The source of the problem can explicitly be traced to file Python-2.1 -main.c, line 287:
  argv[_PyOS_optind] = "-c"; 
        (cf. [ python-Bugs-422678 ] (argv is modified in Py_Main())

which modifies 'argv' as side effect; this then messes up the initialization of 'sys.argv'.

Note: This bug is another side effect of [ python-Bugs-422678 ]

FG


----------------------------------------------------------------------

>Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 11:27

Message:
Logged In: YES 
user_id=93657

I am sorry, but:

- 'some; arg' is a legal Unix/Windows file name
- it is better than than '-c'
- it does not 'bloat' the code, while creating problems elsewhere
- if you really want something 'as good as anything', as you say: --> use '', the empty name, or even None.

I wish you would give a little more consideration, and stop refering me to reference manuals, obfuscating 
the issue, and as if I did not know them.

Thanks,

FG


FG

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-13 11:17

Message:
Logged In: YES 
user_id=31435

Not a bug.  Note also, e.g.,

> python -c "import sys; print sys.argv" a b c
['-c', 'a', 'b', 'c']

See the docs for sys.argv (in the Library manual) -- this 
is the documented and intended behavior.  argv[0] is (as 
also in C) supposed to be the name of the script, but when 
the script is passed literally on the cmdline there is no 
sensible name.  "-c" is as good as anything then.  
*Something* name-like must be passed in argv[0] else code 
that examines sys.argv would have to know whether or not 
Python started via -c.

argv[1:] is supposed contain the arguments to the script.  
Since the expression following -c *is* the script, it would 
be incorrect to leave that in argv:  the script is not an 
argument to itself, after all.


----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 11:17

Message:
Logged In: YES 
user_id=93657

Actually, I need to correct something.

When using 'python -c "some; cmd", the expected value for sys.argv would be either:
  [ ''] # sys.argv value in interactive mode -> sys.argv[ 0] == ''
or
  [ 'some; cmd'] # value of the '-c' option: -> sys.argv[ 0] == 'some; cmd' - this contains more information

In this case, lines 283-288 from main.c could just be deleted.

FG


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423728&group_id=5470


From noreply@sourceforge.net  Sun May 13 19:50:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 11:50:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-423728 ] improper value of sys.argv with '-c' opt
Message-ID: <E14z0x5-0005lz-00@usw-sf-web2.sourceforge.net>

Bugs item #423728, was updated on 2001-05-13 08:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423728&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: improper value of sys.argv with '-c' opt

Initial Comment:

Python 2,1 gives the following result:

---
python -c "import sys; print sys.argv"
[ '-c']
---

This is uncorrect and error-prone.

The two (possible) correct answers are:
    [] # strip off the '-c' stuff
  or
    [ '-c', 'import sys; print sys.argv'] # keep the '-c' stuff

  but ['-c'] alone is definitely uncorrect, as well as it does not make sense.

The source of the problem can explicitly be traced to file Python-2.1 -main.c, line 287:
  argv[_PyOS_optind] = "-c"; 
        (cf. [ python-Bugs-422678 ] (argv is modified in Py_Main())

which modifies 'argv' as side effect; this then messes up the initialization of 'sys.argv'.

Note: This bug is another side effect of [ python-Bugs-422678 ]

FG


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-13 11:50

Message:
Logged In: YES 
user_id=31435

Passing "-c" in this situation has been documented behavior 
for 10 years:  we couldn't change that now even if we 
wanted to.  That's why I pointed you to the docs (which 
this report showed no awareness of).


----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 11:27

Message:
Logged In: YES 
user_id=93657

I am sorry, but:

- 'some; arg' is a legal Unix/Windows file name
- it is better than than '-c'
- it does not 'bloat' the code, while creating problems elsewhere
- if you really want something 'as good as anything', as you say: --> use '', the empty name, or even None.

I wish you would give a little more consideration, and stop refering me to reference manuals, obfuscating 
the issue, and as if I did not know them.

Thanks,

FG


FG

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-13 11:17

Message:
Logged In: YES 
user_id=31435

Not a bug.  Note also, e.g.,

> python -c "import sys; print sys.argv" a b c
['-c', 'a', 'b', 'c']

See the docs for sys.argv (in the Library manual) -- this 
is the documented and intended behavior.  argv[0] is (as 
also in C) supposed to be the name of the script, but when 
the script is passed literally on the cmdline there is no 
sensible name.  "-c" is as good as anything then.  
*Something* name-like must be passed in argv[0] else code 
that examines sys.argv would have to know whether or not 
Python started via -c.

argv[1:] is supposed contain the arguments to the script.  
Since the expression following -c *is* the script, it would 
be incorrect to leave that in argv:  the script is not an 
argument to itself, after all.


----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 11:17

Message:
Logged In: YES 
user_id=93657

Actually, I need to correct something.

When using 'python -c "some; cmd", the expected value for sys.argv would be either:
  [ ''] # sys.argv value in interactive mode -> sys.argv[ 0] == ''
or
  [ 'some; cmd'] # value of the '-c' option: -> sys.argv[ 0] == 'some; cmd' - this contains more information

In this case, lines 283-288 from main.c could just be deleted.

FG


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423728&group_id=5470


From noreply@sourceforge.net  Sun May 13 20:41:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 12:41:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-423728 ] improper value of sys.argv with '-c' opt
Message-ID: <E14z1kZ-0003Uo-00@usw-sf-web1.sourceforge.net>

Bugs item #423728, was updated on 2001-05-13 08:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423728&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: improper value of sys.argv with '-c' opt

Initial Comment:

Python 2,1 gives the following result:

---
python -c "import sys; print sys.argv"
[ '-c']
---

This is uncorrect and error-prone.

The two (possible) correct answers are:
    [] # strip off the '-c' stuff
  or
    [ '-c', 'import sys; print sys.argv'] # keep the '-c' stuff

  but ['-c'] alone is definitely uncorrect, as well as it does not make sense.

The source of the problem can explicitly be traced to file Python-2.1 -main.c, line 287:
  argv[_PyOS_optind] = "-c"; 
        (cf. [ python-Bugs-422678 ] (argv is modified in Py_Main())

which modifies 'argv' as side effect; this then messes up the initialization of 'sys.argv'.

Note: This bug is another side effect of [ python-Bugs-422678 ]

FG


----------------------------------------------------------------------

>Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 12:41

Message:
Logged In: YES 
user_id=93657


Come on... this would be one of the least minor changes ever submitted, and it will be for all the better in 
regard to Python's technical quality (coherency, robustness, and ease of integration into other systems).

I can't see any down-sides to the change, and you could hardly thing of a smallest and easiest patch.

I tested the change, and submitted the patch (patch number 423759): it is the suppression of one single 
line in the source code, and updating the LaTex documentation for sys.argv.

Thanks,

FG


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-13 11:50

Message:
Logged In: YES 
user_id=31435

Passing "-c" in this situation has been documented behavior 
for 10 years:  we couldn't change that now even if we 
wanted to.  That's why I pointed you to the docs (which 
this report showed no awareness of).


----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 11:27

Message:
Logged In: YES 
user_id=93657

I am sorry, but:

- 'some; arg' is a legal Unix/Windows file name
- it is better than than '-c'
- it does not 'bloat' the code, while creating problems elsewhere
- if you really want something 'as good as anything', as you say: --> use '', the empty name, or even None.

I wish you would give a little more consideration, and stop refering me to reference manuals, obfuscating 
the issue, and as if I did not know them.

Thanks,

FG


FG

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-13 11:17

Message:
Logged In: YES 
user_id=31435

Not a bug.  Note also, e.g.,

> python -c "import sys; print sys.argv" a b c
['-c', 'a', 'b', 'c']

See the docs for sys.argv (in the Library manual) -- this 
is the documented and intended behavior.  argv[0] is (as 
also in C) supposed to be the name of the script, but when 
the script is passed literally on the cmdline there is no 
sensible name.  "-c" is as good as anything then.  
*Something* name-like must be passed in argv[0] else code 
that examines sys.argv would have to know whether or not 
Python started via -c.

argv[1:] is supposed contain the arguments to the script.  
Since the expression following -c *is* the script, it would 
be incorrect to leave that in argv:  the script is not an 
argument to itself, after all.


----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 11:17

Message:
Logged In: YES 
user_id=93657

Actually, I need to correct something.

When using 'python -c "some; cmd", the expected value for sys.argv would be either:
  [ ''] # sys.argv value in interactive mode -> sys.argv[ 0] == ''
or
  [ 'some; cmd'] # value of the '-c' option: -> sys.argv[ 0] == 'some; cmd' - this contains more information

In this case, lines 283-288 from main.c could just be deleted.

FG


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423728&group_id=5470


From noreply@sourceforge.net  Sun May 13 21:28:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 13:28:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-423779 ] sgmllib.py not good at handling <br/>
Message-ID: <E14z2Te-0006rM-00@usw-sf-web2.sourceforge.net>

Bugs item #423779, was updated on 2001-05-13 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423779&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib.py not good at handling <br/>

Initial Comment:
When parsing the following HTML:

'Roses <b>are</B> red,<br/>violets <i>are</i> blue'

...with the following class:

class HTML2SafeHTML(sgmllib.SGMLParser):
    
    def handle_data(self, data):
        print "***data***"
        print data

    def unknown_starttag(self, tag, attrs):
        print "***start**"
        print tag
        pprint (attrs)
        pprint (self.openTags)
                
    def unknown_endtag(self, tag):
        print "***end**"
        print tag
        pprint (self.openTags)

I get the following output, which isn't right :-S

***data***
Roses
***start**
b
[]
[]
***data***
are
***end**
b
['b']
***data***
 red,
***start**
br
[]
[]
***data***
>violets <i>are<
***end**
br
[]
***data***
i> blue

cheers,

Chris

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423779&group_id=5470


From noreply@sourceforge.net  Sun May 13 21:30:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 13:30:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-423781 ] pprint.isrecursive() broken
Message-ID: <E14z2VS-0004K0-00@usw-sf-web1.sourceforge.net>

Bugs item #423781, was updated on 2001-05-13 13:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423781&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Moshe Zadka (moshez)
Summary: pprint.isrecursive() broken

Initial Comment:
Assigned to Moshe because mathematicians love 
recursion <wink>.  The code is clearly broken, but 
it's not immediately clear how to fix it.

>From c.l.py:


-----Original Message-----
From: python-list-admin@python.org
    On Behalf Of Roman Suzi
Sent: Sunday, May 13, 2001 3:36 PM
To: python-list@python.org
Subject: pprint.isrecursive: is it ever recursive? (a 
bug?)


Hello!

I was looking at pprint code and out of curiosity tried
to repr self-referencing list:

>>> import pprint
>>> l=[1,2]
>>> l[0]=l
>>> pprint.isreadable(l)
0
>>> pprint.isrecursive(l)
0
>>> l
[[...], 2]
>>> pprint.saferepr(l)
'[<Recursion on list with id=135078960>, 2]'
>>>


However, it seems to me that isrecursive(l) must be 1, 
not 0.  Or do I misunderstand it's meaning?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423781&group_id=5470


From noreply@sourceforge.net  Mon May 14 02:51:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 18:51:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-417472 ] Unneccessary warning message
Message-ID: <E14z7WR-0000zm-00@usw-sf-web1.sourceforge.net>

Bugs item #417472, was updated on 2001-04-19 15:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417472&group_id=5470

Category: Distutils
Group: Not a Bug
Status: Open
Resolution: None
Priority: 2
Submitted By: Viktor Ferenczi (complex)
Assigned to: Greg Ward (gward)
Summary: Unneccessary warning message

Initial Comment:
Unneccessary warning message near to the end of Python
2.1 compilation:

warning: install: modules installed to
'/usr/local/lib/python2.1/lib-dynload/',
which is not in Python's module search path (sys.path)
-- you'll have to change
the search path yourself

The search path contains the
/usr/local/lib/python2.1/lib-dynload directory,
so this warning message is not required.

System: RedHat Linux 7.0 (Kernel 2.2.17, gcc 2.96)

- Complex -

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-13 18:51

Message:
Logged In: YES 
user_id=149084

Patch 423830 Submitted

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-11 16:15

Message:
Logged In: YES 
user_id=149084

Duplicate of Bug 232619....

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 09:45

Message:
Logged In: YES 
user_id=3066

This appears to be a distutils-generated message, so I'm
assigning this to the distutils guru.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417472&group_id=5470


From noreply@sourceforge.net  Mon May 14 02:53:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 18:53:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-232619 ] 2.1a2 misleading comment from "make install" (minor nit)
Message-ID: <E14z7YO-00011J-00@usw-sf-web1.sourceforge.net>

Bugs item #232619, was updated on 2001-02-15 14:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232619&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: A.M. Kuchling (akuchling)
Summary: 2.1a2 misleading comment from "make install" (minor nit)

Initial Comment:
Towards the end of the output from "make install" (using current - Feb 16 - CVS) appears the following:

warning: install: modules installed to '/usr/local/lib/python2.1/lib-dynload/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself

This is misleading, as /usr/local/lib/python2.1/lib-dynload is indeed in the newly installed python's sys.path - just not in the sys.path of the just-built-but-not-installed python.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-13 18:53

Message:
Logged In: YES 
user_id=149084

Patch 423830 Submitted

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-28 11:30

Message:
Logged In: YES 
user_id=3066

Andrew, this looks related to the move to distutils for building the standard library extension modules.  Can you handle it please?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232619&group_id=5470


From noreply@sourceforge.net  Mon May 14 07:04:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 23:04:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-423851 ] Python 2.1 Falling Over On Win2K
Message-ID: <E14zBT0-0006nU-00@usw-sf-web3.sourceforge.net>

Bugs item #423851, was updated on 2001-05-13 23:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423851&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 Falling Over On Win2K

Initial Comment:
Platform: Windows 2000

Python Version: 2.1

Box: AMD Thunderbird 750 with 128meg

Hi,

I don't know if anyone else has experienced this so I 
will put it out there regardless.

I have been using the distribution of Python 2.1 which 
comes with ActiveState ActivePython.

If I walk a directory using the os.path.walk module 
and return the results to a list and then try to 
display this list, Python falls flat on it's face and 
shuts down. 

However this does not occur when using Python 2.0.

The piece of code I have been using is as follows:

import os


def walker(arg, dirname, filenames):
    # Create A List Of Files In A Directory
    for files in filenames:
        arg.append(os.path.join(dirname, files))

DirLst = []

os.path.walk('c:\test\', walker, DirLst)

DirLst # At this point the command should display the 
list to the screen, instead the program shuts itself 
down




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423851&group_id=5470


From noreply@sourceforge.net  Mon May 14 07:43:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 23:43:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-423851 ] Python 2.1 Falling Over On Win2K
Message-ID: <E14zC4b-0004id-00@usw-sf-web2.sourceforge.net>

Bugs item #423851, was updated on 2001-05-13 23:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423851&group_id=5470

Category: Windows
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Paul Prescod (prescod)
Summary: Python 2.1 Falling Over On Win2K

Initial Comment:
Platform: Windows 2000

Python Version: 2.1

Box: AMD Thunderbird 750 with 128meg

Hi,

I don't know if anyone else has experienced this so I 
will put it out there regardless.

I have been using the distribution of Python 2.1 which 
comes with ActiveState ActivePython.

If I walk a directory using the os.path.walk module 
and return the results to a list and then try to 
display this list, Python falls flat on it's face and 
shuts down. 

However this does not occur when using Python 2.0.

The piece of code I have been using is as follows:

import os


def walker(arg, dirname, filenames):
    # Create A List Of Files In A Directory
    for files in filenames:
        arg.append(os.path.join(dirname, files))

DirLst = []

os.path.walk('c:\test\', walker, DirLst)

DirLst # At this point the command should display the 
list to the screen, instead the program shuts itself 
down




----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-13 23:43

Message:
Logged In: YES 
user_id=31435

Assigned to Paul.

Worked fine for me on a directory w/ over 10,000 files 
under it, but I'm not using the ActiveState distribution.  
If this is specific to ActiveState Python, you should 
report the bug to them.

"Falls on its face and shuts down" doesn't mean anything to 
me.  Were you running from a DOS box Python, or perhaps 
from within PythonWin, or Komodo, or ...?  Not enough info 
here.  I tried it from a DOS box Python.  If it works for 
you under a DOS box Python, then problems specific to 
PythonWin or Komodo definitely don't belong here.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423851&group_id=5470


From noreply@sourceforge.net  Mon May 14 07:44:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 13 May 2001 23:44:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-423781 ] pprint.isrecursive() broken
Message-ID: <E14zC5T-0004jJ-00@usw-sf-web2.sourceforge.net>

Bugs item #423781, was updated on 2001-05-13 13:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423781&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: pprint.isrecursive() broken

Initial Comment:
Assigned to Moshe because mathematicians love 
recursion <wink>.  The code is clearly broken, but 
it's not immediately clear how to fix it.

>From c.l.py:


-----Original Message-----
From: python-list-admin@python.org
    On Behalf Of Roman Suzi
Sent: Sunday, May 13, 2001 3:36 PM
To: python-list@python.org
Subject: pprint.isrecursive: is it ever recursive? (a 
bug?)


Hello!

I was looking at pprint code and out of curiosity tried
to repr self-referencing list:

>>> import pprint
>>> l=[1,2]
>>> l[0]=l
>>> pprint.isreadable(l)
0
>>> pprint.isrecursive(l)
0
>>> l
[[...], 2]
>>> pprint.saferepr(l)
'[<Recursion on list with id=135078960>, 2]'
>>>


However, it seems to me that isrecursive(l) must be 1, 
not 0.  Or do I misunderstand it's meaning?


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-13 23:44

Message:
Logged In: YES 
user_id=31435

Assigned to me -- the pprint code isn't even close to 
working correctly.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423781&group_id=5470


From noreply@sourceforge.net  Mon May 14 08:07:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 14 May 2001 00:07:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-423781 ] pprint.isrecursive() broken
Message-ID: <E14zCS4-0005yJ-00@usw-sf-web1.sourceforge.net>

Bugs item #423781, was updated on 2001-05-13 13:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423781&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: pprint.isrecursive() broken

Initial Comment:
Assigned to Moshe because mathematicians love 
recursion <wink>.  The code is clearly broken, but 
it's not immediately clear how to fix it.

>From c.l.py:


-----Original Message-----
From: python-list-admin@python.org
    On Behalf Of Roman Suzi
Sent: Sunday, May 13, 2001 3:36 PM
To: python-list@python.org
Subject: pprint.isrecursive: is it ever recursive? (a 
bug?)


Hello!

I was looking at pprint code and out of curiosity tried
to repr self-referencing list:

>>> import pprint
>>> l=[1,2]
>>> l[0]=l
>>> pprint.isreadable(l)
0
>>> pprint.isrecursive(l)
0
>>> l
[[...], 2]
>>> pprint.saferepr(l)
'[<Recursion on list with id=135078960>, 2]'
>>>


However, it seems to me that isrecursive(l) must be 1, 
not 0.  Or do I misunderstand it's meaning?


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-14 00:07

Message:
Logged In: YES 
user_id=31435

I don't see how this code ever could have 
worked:  .isrecursive() and .isreadable() were calling a 
wrong function (they're supposed to test saferepr(), not 
PrettyPrinter()), and the underlying _safe_repr function 
wasn't returning any info about whether the object was 
recursive.

Fixed now:

Lib/pprint.py new revision: 1.13
Lib/test/test_pprint.py initial revision: 1.1
Lib/test/output/test_pprint initial revision: 1.1
Misc/NEWS new revision: 1.168


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-13 23:44

Message:
Logged In: YES 
user_id=31435

Assigned to me -- the pprint code isn't even close to 
working correctly.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423781&group_id=5470


From noreply@sourceforge.net  Mon May 14 08:47:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 14 May 2001 00:47:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-423728 ] improper value of sys.argv with '-c' opt
Message-ID: <E14zD51-0005T3-00@usw-sf-web2.sourceforge.net>

Bugs item #423728, was updated on 2001-05-13 08:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423728&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: improper value of sys.argv with '-c' opt

Initial Comment:

Python 2,1 gives the following result:

---
python -c "import sys; print sys.argv"
[ '-c']
---

This is uncorrect and error-prone.

The two (possible) correct answers are:
    [] # strip off the '-c' stuff
  or
    [ '-c', 'import sys; print sys.argv'] # keep the '-c' stuff

  but ['-c'] alone is definitely uncorrect, as well as it does not make sense.

The source of the problem can explicitly be traced to file Python-2.1 -main.c, line 287:
  argv[_PyOS_optind] = "-c"; 
        (cf. [ python-Bugs-422678 ] (argv is modified in Py_Main())

which modifies 'argv' as side effect; this then messes up the initialization of 'sys.argv'.

Note: This bug is another side effect of [ python-Bugs-422678 ]

FG


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-14 00:47

Message:
Logged In: YES 
user_id=31435

Changing documented behavior is always a risk, so is never 
done lightly.  The tradeoff you propose here is that we 
break long-documented behavior so that you don't have to 
fix your own code that made a bad assumption about an 
undocumented internal C API function.

That isn't an argument for incompatible behavior I could 
sell to anyone -- and I bet not even to you a month from 
now.  Changing -c behavior is simply a bad idea.  I have a 
lot more sympathy for the original bug report (this one 
wasn't even reporting a *problem*:  the original claims in 
this report that current -c behavior is "uncorrect and 
error-prone" and "definitely uncorrect" and "does not make 
sense" were wrong on all counts, as you yourself realized 
by the time you added your first comment, retracting your 
original two (claimed to be) "correct" suggestions).

BTW, if you look at the timestamps, you'll see that I was 
writing my first comment at the same time you were writing 
yours:  I had not seen your first comment by the time I 
wrote my first.  Given the unbroken successsion of 
incorrect claims in the original bug report to which I was 
responding, I think my first comment showed all the 
consideration it deserved, and then some.


----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 12:41

Message:
Logged In: YES 
user_id=93657


Come on... this would be one of the least minor changes ever submitted, and it will be for all the better in 
regard to Python's technical quality (coherency, robustness, and ease of integration into other systems).

I can't see any down-sides to the change, and you could hardly thing of a smallest and easiest patch.

I tested the change, and submitted the patch (patch number 423759): it is the suppression of one single 
line in the source code, and updating the LaTex documentation for sys.argv.

Thanks,

FG


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-13 11:50

Message:
Logged In: YES 
user_id=31435

Passing "-c" in this situation has been documented behavior 
for 10 years:  we couldn't change that now even if we 
wanted to.  That's why I pointed you to the docs (which 
this report showed no awareness of).


----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 11:27

Message:
Logged In: YES 
user_id=93657

I am sorry, but:

- 'some; arg' is a legal Unix/Windows file name
- it is better than than '-c'
- it does not 'bloat' the code, while creating problems elsewhere
- if you really want something 'as good as anything', as you say: --> use '', the empty name, or even None.

I wish you would give a little more consideration, and stop refering me to reference manuals, obfuscating 
the issue, and as if I did not know them.

Thanks,

FG


FG

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-13 11:17

Message:
Logged In: YES 
user_id=31435

Not a bug.  Note also, e.g.,

> python -c "import sys; print sys.argv" a b c
['-c', 'a', 'b', 'c']

See the docs for sys.argv (in the Library manual) -- this 
is the documented and intended behavior.  argv[0] is (as 
also in C) supposed to be the name of the script, but when 
the script is passed literally on the cmdline there is no 
sensible name.  "-c" is as good as anything then.  
*Something* name-like must be passed in argv[0] else code 
that examines sys.argv would have to know whether or not 
Python started via -c.

argv[1:] is supposed contain the arguments to the script.  
Since the expression following -c *is* the script, it would 
be incorrect to leave that in argv:  the script is not an 
argument to itself, after all.


----------------------------------------------------------------------

Comment By: Frederic Giacometti (giacometti)
Date: 2001-05-13 11:17

Message:
Logged In: YES 
user_id=93657

Actually, I need to correct something.

When using 'python -c "some; cmd", the expected value for sys.argv would be either:
  [ ''] # sys.argv value in interactive mode -> sys.argv[ 0] == ''
or
  [ 'some; cmd'] # value of the '-c' option: -> sys.argv[ 0] == 'some; cmd' - this contains more information

In this case, lines 283-288 from main.c could just be deleted.

FG


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423728&group_id=5470


From noreply@sourceforge.net  Mon May 14 17:05:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 14 May 2001 09:05:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-423429 ] very minor nit in library ref
Message-ID: <E14zKqk-0006ot-00@usw-sf-web1.sourceforge.net>

Bugs item #423429, was updated on 2001-05-11 13:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423429&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michel Pelletier (michel)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: very minor nit in library ref

Initial Comment:
http://www.python.org/doc/current/ref/types.html

says "Python distinguishes between integers and
floating point numbers:"

but then goes on to list integer, floating point, and
complex numbers.  It should mention complex numbers in
that sentence.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-14 09:05

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/ref/ref3.tex revisions 1.66 and 1.64.2.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423429&group_id=5470


From noreply@sourceforge.net  Mon May 14 18:38:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 14 May 2001 10:38:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-422203 ] math.sqrt() broken on parisc-linux
Message-ID: <E14zMIr-0003zH-00@usw-sf-web2.sourceforge.net>

Bugs item #422203, was updated on 2001-05-07 22:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422203&group_id=5470

Category: Extension Modules
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Submitted By: dann frazier (dannf)
Assigned to: Tim Peters (tim_one)
Summary: math.sqrt() broken on parisc-linux

Initial Comment:
python 2.0
Debian GNU/Linux on PA-RISC
package: python2-base_2.0-7

for any integer x, math.sqrt(x.0) seems to equal 0.0

----
sebadoh:/tmp# python2
Python 2.0 (#0, Apr 27 2001, 03:16:35) 
[GCC 3.0 20010315 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import math
>>> math.sqrt(2.0)
0.0
>>> math.sqrt(2)
1.4142135623730951
----

the C equivalent (math.h) reports the correct answer.

sebadoh:/tmp# uname -a
Linux sebadoh 2.4.0 #1 Mon May 7 12:41:27 MDT 2001
parisc unknown


----------------------------------------------------------------------

>Comment By: dann frazier (dannf)
Date: 2001-05-14 10:38

Message:
Logged In: YES 
user_id=146718

ok, this appears to be a bug in glibc on this platform, not
python.
closing....

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-11 13:03

Message:
Logged In: YES 
user_id=31435

If we don't get more info here soon, I'm going to just 
close this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 22:27

Message:
Logged In: YES 
user_id=31435

Try recompiling with optimization off?  Python is written 
in C, and calls the same libm sqrt function you call when 
you write a C program.  It's very straightforward.  Nobody 
else has reported this problem, so there's something unique 
about your platform, and a buggy compiler is always the 
first guess when that occurs.

Also try a current version of Python (2.1 is current; 2.0 
is no longer supported officially, although a volunteer may 
produce a bugfix release for it).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422203&group_id=5470


From noreply@sourceforge.net  Mon May 14 19:17:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 14 May 2001 11:17:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-424002 ] sys.executable not reliable
Message-ID: <E14zMuJ-0004Tt-00@usw-sf-web2.sourceforge.net>

Bugs item #424002, was updated on 2001-05-14 11:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424002&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Evan Simpson (evansimpson)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.executable not reliable

Initial Comment:
I created a file test.py containing:

#!/usr/local/bin/python2.1
import sys
print sys.executable

When I run it using the command 
line "/usr/local/bin/python2.1 test.py", it prints the 
full path to the executable.  When I run it 
from "/usr/local", using "bin/python2.1 test.py", then 
I get "bin/python2.1".  When I run it 
using "./test.py", I get a blank string.

Under version 1.5.2, all of these yielded the full 
path to the executable.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424002&group_id=5470


From noreply@sourceforge.net  Mon May 14 23:14:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 14 May 2001 15:14:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-423851 ] Python 2.1 Falling Over On Win2K
Message-ID: <E14zQbx-00055W-00@usw-sf-web1.sourceforge.net>

Bugs item #423851, was updated on 2001-05-13 23:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423851&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Paul Prescod (prescod)
Summary: Python 2.1 Falling Over On Win2K

Initial Comment:
Platform: Windows 2000

Python Version: 2.1

Box: AMD Thunderbird 750 with 128meg

Hi,

I don't know if anyone else has experienced this so I 
will put it out there regardless.

I have been using the distribution of Python 2.1 which 
comes with ActiveState ActivePython.

If I walk a directory using the os.path.walk module 
and return the results to a list and then try to 
display this list, Python falls flat on it's face and 
shuts down. 

However this does not occur when using Python 2.0.

The piece of code I have been using is as follows:

import os


def walker(arg, dirname, filenames):
    # Create A List Of Files In A Directory
    for files in filenames:
        arg.append(os.path.join(dirname, files))

DirLst = []

os.path.walk('c:\test\', walker, DirLst)

DirLst # At this point the command should display the 
list to the screen, instead the program shuts itself 
down




----------------------------------------------------------------------

>Comment By: Paul Prescod (prescod)
Date: 2001-05-14 15:14

Message:
Logged In: YES 
user_id=31788

I am trying, somewhat, to read the poster's mind. But I'm guessing that the problem has nothing to do with 
Python or ActivePython. Instead of trying to print the list to the screen, write it to a file like this:

open("foo", "w").write(repr(DirLst))

Writing it to the screen may trigger a bug in Scintilla which is used in PythonWin relating to long lines.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-13 23:43

Message:
Logged In: YES 
user_id=31435

Assigned to Paul.

Worked fine for me on a directory w/ over 10,000 files 
under it, but I'm not using the ActiveState distribution.  
If this is specific to ActiveState Python, you should 
report the bug to them.

"Falls on its face and shuts down" doesn't mean anything to 
me.  Were you running from a DOS box Python, or perhaps 
from within PythonWin, or Komodo, or ...?  Not enough info 
here.  I tried it from a DOS box Python.  If it works for 
you under a DOS box Python, then problems specific to 
PythonWin or Komodo definitely don't belong here.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423851&group_id=5470


From noreply@sourceforge.net  Tue May 15 02:30:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 14 May 2001 18:30:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-424106 ] PyImport_ExecCodeModule not correct
Message-ID: <E14zTfZ-0000Kd-00@usw-sf-web1.sourceforge.net>

Bugs item #424106, was updated on 2001-05-14 18:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424106&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyImport_ExecCodeModule not correct

Initial Comment:
PyImport_ExecCodeModule doesn't handle package imports
correctly. Using it to import a module "A.B" will
result in an entry in sys.modules of "A.B" but no
information for module "A" will be created. The
documentation in the C API reference makes no statement
about this - just that the module name may be of the
form "package.module". Looking at the code in import.c,
there is definitely no handling of the package. If this
is the intended behaviour, please amend the
documentation (and possibly give some hint as to how
one _should_ go about importing a code object in a
package structure ;)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424106&group_id=5470


From noreply@sourceforge.net  Wed May 16 09:34:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 May 2001 01:34:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-423721 ] failure in urllib exception handling
Message-ID: <E14zwlA-0006z5-00@usw-sf-web1.sourceforge.net>

Bugs item #423721, was updated on 2001-05-13 07:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423721&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Becker (rgbecker)
Assigned to: Nobody/Anonymous (nobody)
Summary: failure in urllib exception handling

Initial Comment:
This is observed sometimes using webchecker.py running python 2.0 under freeBSD 4.2
seems like urllib might checking strings against Exception instances

webchecker version 1.22

Round 1 (1 total, 1 to do, 0 done, 0 bad)


Round 2 (20 total, 19 to do, 1 done, 0 bad)


Round 3 (117 total, 97 to do, 20 done, 0 bad)


Saving checkpoint to @webchecker.pickle ...
Done.
Use ``/usr/local/lib/python2.0/Tools/webchecker/webchecker.py -R'' to
restart.
Traceback (most recent call last):
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
824, in ?
    main()
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
222, in main
    c.run()
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
349, in run
    self.dopage(url)
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
403, in dopage
    page = self.getpage(url_pair)
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
496, in getpage
    f = self.openpage(url_pair)
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
534, in openpage
    return self.urlopener.open(url)
  File "/usr/local/lib/python2.0/urllib.py", line 166, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.0/urllib.py", line 457, in open_ftp
    (fp, retrlen) = self.ftpcache[key].retrfile(file, type)
  File "/usr/local/lib/python2.0/urllib.py", line 692, in retrfile
    if reason[:3] != '550':
TypeError: sequence index must be integer

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-16 01:34

Message:
Logged In: NO 

"reason" is an ftp error exception instance, which
doesn't support slicing.  changing this to

    if str(reason)[:3] != "550"

should work.

is this bug still present in 2.1?  (only have 2.0 on
the box I'm typing this on)

</F>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423721&group_id=5470


From noreply@sourceforge.net  Wed May 16 16:11:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 May 2001 08:11:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-424552 ] Example function # 4.4 is incorrect
Message-ID: <E1502xA-0007cP-00@usw-sf-web2.sourceforge.net>

Bugs item #424552, was updated on 2001-05-16 08:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424552&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Example function # 4.4 is incorrect

Initial Comment:
(Refers to the online tutorial at 
http://www.python.org/doc/current/tut/node6.html#SECTIO
N006400000000000000000)

The code should be changed to:

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...             print n, 'equals', x, '*', n/x
...             break 
...         elif x < (n-1) :
...             continue # keep checking
...         else:
...             print n, 'is a prime number'



Otherwise, you will get multiple "7 is a prime number" 
statements with the current code. Also, if would 
incorrectly say "9 is a prime number" and "9 equals 3 
* 3". I added the elif/continue part to take care of 
these two problems.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424552&group_id=5470


From noreply@sourceforge.net  Wed May 16 16:41:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 May 2001 08:41:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-424552 ] Example function # 4.4 is incorrect
Message-ID: <E1503Qt-000606-00@usw-sf-web1.sourceforge.net>

Bugs item #424552, was updated on 2001-05-16 08:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424552&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Example function # 4.4 is incorrect

Initial Comment:
(Refers to the online tutorial at 
http://www.python.org/doc/current/tut/node6.html#SECTIO
N006400000000000000000)

The code should be changed to:

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...             print n, 'equals', x, '*', n/x
...             break 
...         elif x < (n-1) :
...             continue # keep checking
...         else:
...             print n, 'is a prime number'



Otherwise, you will get multiple "7 is a prime number" 
statements with the current code. Also, if would 
incorrectly say "9 is a prime number" and "9 equals 3 
* 3". I added the elif/continue part to take care of 
these two problems.



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-16 08:41

Message:
Logged In: YES 
user_id=3066

I'll add a comment to the "else" clause of the for loop in  a future checkin, but the code is correct.

(The submitter admitted he made an indentation error in a followup email.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424552&group_id=5470


From noreply@sourceforge.net  Wed May 16 16:54:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 May 2001 08:54:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-423779 ] sgmllib.py not good at handling <br/>
Message-ID: <E1503dQ-0006CF-00@usw-sf-web1.sourceforge.net>

Bugs item #423779, was updated on 2001-05-13 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423779&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Withers (fresh)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sgmllib.py not good at handling <br/>

Initial Comment:
When parsing the following HTML:

'Roses <b>are</B> red,<br/>violets <i>are</i> blue'

...with the following class:

class HTML2SafeHTML(sgmllib.SGMLParser):
    
    def handle_data(self, data):
        print "***data***"
        print data

    def unknown_starttag(self, tag, attrs):
        print "***start**"
        print tag
        pprint (attrs)
        pprint (self.openTags)
                
    def unknown_endtag(self, tag):
        print "***end**"
        print tag
        pprint (self.openTags)

I get the following output, which isn't right :-S

***data***
Roses
***start**
b
[]
[]
***data***
are
***end**
b
['b']
***data***
 red,
***start**
br
[]
[]
***data***
>violets <i>are<
***end**
br
[]
***data***
i> blue

cheers,

Chris

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-16 08:54

Message:
Logged In: YES 
user_id=3066

While there is definately space for improvement in sgmllib, and probably a need for a few bug fixes, it is not clear that this is one of the bugs.

SGML defines something called the "null end tag" (NET) and the "NET enabler".  In a document, this looks like:

    <tag/ content /

This represents an element "tag" with the content " content ".  The first slash is the enabler and the second is the NET.  Basic support for this has been a part of sgmllib for as long as I can remember; it was added before I started playing with it.

In practice, use of the NET in HTML doesn't seem to exist.  Perhaps it should be something that can be specifically enabled or disabled?  I'm more inclined to say that sgmllib should not be used for XHTML though -- XHTML is *not* SGML, it's XML, and that's something different.

Have you tried to apply xmllib to your application?  Given your desire (stated elsewhere) to work with seriously broken HTML as well, you may be better off using a custom parser similar to TAL.HTMLParser used by PageTemplates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423779&group_id=5470


From noreply@sourceforge.net  Wed May 16 23:33:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 16 May 2001 15:33:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-424680 ] distutils module version # not StrictVer
Message-ID: <E1509rA-0005gn-00@usw-sf-web3.sourceforge.net>

Bugs item #424680, was updated on 2001-05-16 15:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424680&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils module version # not StrictVer

Initial Comment:
There is a fairly detailed definition in the distutils 
module (in version.py) about valid (or Strict) version 
numbers.  However the version number of the distutils 
module does not conform to this numbering scheme.  
Specifically 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import distutils
>>> distutils.__version__
'1.0.2pre'
>>> from distutils.version import StrictVersion
>>> StrictVersion(distutils.__version__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\program files\python21
\lib\distutils\version.py", line 42, in __init__
    self.parse(vstring)
  File "c:\program files\python21
\lib\distutils\version.py", line 109, in parse
    raise ValueError, "invalid version number '%s'" % 
vstring
ValueError: invalid version number '1.0.2pre'
>>>




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424680&group_id=5470


From noreply@sourceforge.net  Thu May 17 08:54:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 00:54:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-424776 ] SMTP Example does not work
Message-ID: <E150Ibh-0004GP-00@usw-sf-web3.sourceforge.net>

Bugs item #424776, was updated on 2001-05-17 00:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424776&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: SMTP Example does not work

Initial Comment:
Maybe no one tried it for a long time ... the SMTP
example in the 2.1 version of the smtplib part of
'Python Library Reference' uses 'rawinput()' to read
from input. When the 'user' termninates his message
with ^D, rawinput raises EOFError, which is not catched
in this code, which probably should be changed to

while 1:
  try:
    line = raw_input()
  except EOFError:
    break
  msg = msg + line

Regards,
Matthias

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424776&group_id=5470


From noreply@sourceforge.net  Thu May 17 20:31:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 12:31:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-424951 ] ThreadingTCPServer file handle errors.
Message-ID: <E150TUc-000571-00@usw-sf-web3.sourceforge.net>

Bugs item #424951, was updated on 2001-05-17 12:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424951&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Largent (jlargent)
Assigned to: Nobody/Anonymous (nobody)
Summary: ThreadingTCPServer file handle errors.

Initial Comment:
When running a server using ThreadingTCPServer if the
server sit for several minutes between requests the
first request it receives will error with a bad file
handle error.

Python 2.1 (#1, Apr 20 2001, 15:04:11) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2

#!/usr/bin/python2

from SocketServer import ThreadingTCPServer,
BaseRequestHandler



class myHandler (BaseRequestHandler):
    def handle(self):
        while 1:
            data = self.request.recv(1024)
            if not data: break
            
            self.request.send('%s' % (data))
            
        self.request.close

if __name__ == '__main__':
    addr = ('localhost', 50000)
    s = ThreadingTCPServer(addr, myHandler)
    s.serve_forever()

Start this server wait several min then
using the echo-client.py from oreilly Programming
Python to 
send it data.

Traceback (most recent call last):
  File
"/var/tmp/python2-2.1-root/usr/lib/python2.1/threading.py",
line 378, in __bootstrap
    self.run()
  File
"/var/tmp/python2-2.1-root/usr/lib/python2.1/threading.py",
line 366, in run
    apply(self.__target, self.__args, self.__kwargs)
  File
"/var/tmp/python2-2.1-root/usr/lib/python2.1/SocketServer.py",
line 246, in finish_request
    self.RequestHandlerClass(request, client_address,
self)
  File
"/var/tmp/python2-2.1-root/usr/lib/python2.1/SocketServer.py",
line 495, in __init__
    self.handle()
  File "./server.py", line 10, in handle
    data = self.request.recv(1024)
error: (9, 'Bad file descriptor')

Any requests sent right after this will complete
properly.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424951&group_id=5470


From noreply@sourceforge.net  Thu May 17 21:14:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 13:14:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-424962 ] inconsistent result with __eq__
Message-ID: <E150U9p-0000w9-00@usw-sf-web1.sourceforge.net>

Bugs item #424962, was updated on 2001-05-17 13:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424962&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: inconsistent result with __eq__

Initial Comment:
I define __eq__ to allow to check for class equality.
This class contains only one string. I get inconsistent
results (depending 
on the string contained in the class instances (fails
if string contains 
a '-' character).

The attached sample is simple to follow. If you change
the string from "-c" to "c", then the sample works!

Thanks for the great work! I love python.

Gregory Popovitch (greg@gpy.com)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424962&group_id=5470


From noreply@sourceforge.net  Thu May 17 21:43:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 13:43:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-424962 ] inconsistent result with __eq__
Message-ID: <E150UcK-0001oo-00@usw-sf-web2.sourceforge.net>

Bugs item #424962, was updated on 2001-05-17 13:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424962&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: inconsistent result with __eq__

Initial Comment:
I define __eq__ to allow to check for class equality.
This class contains only one string. I get inconsistent
results (depending 
on the string contained in the class instances (fails
if string contains 
a '-' character).

The attached sample is simple to follow. If you change
the string from "-c" to "c", then the sample works!

Thanks for the great work! I love python.

Gregory Popovitch (greg@gpy.com)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-05-17 13:43

Message:
Logged In: YES 
user_id=6656

you have "is"-"==" confusion.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424962&group_id=5470


From noreply@sourceforge.net  Thu May 17 22:49:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 14:49:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-423779 ] sgmllib.py not good at handling <br/>
Message-ID: <E150VeH-0002bh-00@usw-sf-web1.sourceforge.net>

Bugs item #423779, was updated on 2001-05-13 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423779&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sgmllib.py not good at handling <br/>

Initial Comment:
When parsing the following HTML:

'Roses <b>are</B> red,<br/>violets <i>are</i> blue'

...with the following class:

class HTML2SafeHTML(sgmllib.SGMLParser):
    
    def handle_data(self, data):
        print "***data***"
        print data

    def unknown_starttag(self, tag, attrs):
        print "***start**"
        print tag
        pprint (attrs)
        pprint (self.openTags)
                
    def unknown_endtag(self, tag):
        print "***end**"
        print tag
        pprint (self.openTags)

I get the following output, which isn't right :-S

***data***
Roses
***start**
b
[]
[]
***data***
are
***end**
b
['b']
***data***
 red,
***start**
br
[]
[]
***data***
>violets <i>are<
***end**
br
[]
***data***
i> blue

cheers,

Chris

----------------------------------------------------------------------

>Comment By: Chris Withers (fresh)
Date: 2001-05-17 14:49

Message:
Logged In: YES 
user_id=24723

Hmmm, from comments on the Python list, I understood XML to 
be a subset of SGML, implying that sgmlib should at least 
do something sensible with the stuff above ;-)

That said, I'm not too fussed about this anymore as 
TAL.HTMLParser solved all of my problems.
Is this the right place to beg for it to be included in the 
standard python distribution?

Thanks for your help,

Chris

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-16 08:54

Message:
Logged In: YES 
user_id=3066

While there is definately space for improvement in sgmllib, and probably a need for a few bug fixes, it is not clear that this is one of the bugs.

SGML defines something called the "null end tag" (NET) and the "NET enabler".  In a document, this looks like:

    <tag/ content /

This represents an element "tag" with the content " content ".  The first slash is the enabler and the second is the NET.  Basic support for this has been a part of sgmllib for as long as I can remember; it was added before I started playing with it.

In practice, use of the NET in HTML doesn't seem to exist.  Perhaps it should be something that can be specifically enabled or disabled?  I'm more inclined to say that sgmllib should not be used for XHTML though -- XHTML is *not* SGML, it's XML, and that's something different.

Have you tried to apply xmllib to your application?  Given your desire (stated elsewhere) to work with seriously broken HTML as well, you may be better off using a custom parser similar to TAL.HTMLParser used by PageTemplates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423779&group_id=5470


From noreply@sourceforge.net  Fri May 18 00:28:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 17 May 2001 16:28:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 final broken on Linux!!!
Message-ID: <E150XBt-0008In-00@usw-sf-web3.sourceforge.net>

Bugs item #425007, was updated on 2001-05-17 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 final broken on Linux!!!

Initial Comment:
I have gone back and tried Python 1.6 and 2.0.  Both
work fine.  When I install Python 2.1, everything is
broken.  The problem is that when a module is a shared
library (.so), python refuses to load the module.  Example:

import os
import sys
import SocketServer

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/SocketServer.py", line 126, in ?
    import socket
  File "/usr/lib/python2.1/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket

Now, do a "locate _socket.so" and I get:
/usr/lib/python2.1/site-packages/_socket.so
/usr/lib/python2.1/lib-dynload/_socket.so


Clearly they are there, it's just that Python refuses
to load them.


I made Python 2.1 from source as fetched from the 2.1
tar ball.  It makes cleanly.  During the installation,
I see some items that I believe to be minor that popup,
but don't currectly expect that they are the problem. 
I have tried many times using different configure
options to get this to work, deleting the previous
installation each time.  I've even tried installing in
different locations.

As is, Python 2.1 is completely broken for me.  Surely
I'm not the only one having this problem, especially
since 1.5, 1.6, and 2.0 all work correctly.

Any help would be great.  BTW, doing a "print sys.path"
gives me: ['', '/usr/lib/python2.1',
'/usr/lib/python2.1/plat-linux2',
'/usr/lib/python2.1/lib-tk',
'/usr/lib/python2.1/lib-dynload',
'/usr/lib/python2.1/site-packages']

As you can see, lib-dynload is in the path, so I'm not
really sure what's going on.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470


From noreply@sourceforge.net  Fri May 18 09:57:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 01:57:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-424962 ] inconsistent result with __eq__
Message-ID: <E150g4j-0006eR-00@usw-sf-web3.sourceforge.net>

Bugs item #424962, was updated on 2001-05-17 13:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424962&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: inconsistent result with __eq__

Initial Comment:
I define __eq__ to allow to check for class equality.
This class contains only one string. I get inconsistent
results (depending 
on the string contained in the class instances (fails
if string contains 
a '-' character).

The attached sample is simple to follow. If you change
the string from "-c" to "c", then the sample works!

Thanks for the great work! I love python.

Gregory Popovitch (greg@gpy.com)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-18 01:57

Message:
Logged In: YES 
user_id=31435

As Michael suggested, use "==" instead of "is" and your 
program will work as intended.  "==" is the correct 
operator to test value equality, and your use of "is" here 
simply doesn't make sense.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-05-17 13:43

Message:
Logged In: YES 
user_id=6656

you have "is"-"==" confusion.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424962&group_id=5470


From noreply@sourceforge.net  Fri May 18 18:53:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 10:53:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-425261 ] re propagates opaque exceptions
Message-ID: <E150oQv-0005Ws-00@usw-sf-web1.sourceforge.net>

Bugs item #425261, was updated on 2001-05-18 10:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425261&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: re propagates opaque exceptions

Initial Comment:
If you call re.compile() with an erroneous expression,
the
underlying extension module (pcre, sre, ...?) raises an
exception which is propagated through re to the caller.

In order to catch the exception, it seems that you need
to
use an unqualified except clause, unless you import the
extension module, which is presumably supposed to be
opaque (particularly if its identity is variable!)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425261&group_id=5470


From noreply@sourceforge.net  Fri May 18 21:12:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 13:12:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-425261 ] re propagates opaque exceptions
Message-ID: <E150qcJ-000748-00@usw-sf-web3.sourceforge.net>

Bugs item #425261, was updated on 2001-05-18 10:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425261&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fredrik Lundh (effbot)
Summary: re propagates opaque exceptions

Initial Comment:
If you call re.compile() with an erroneous expression,
the
underlying extension module (pcre, sre, ...?) raises an
exception which is propagated through re to the caller.

In order to catch the exception, it seems that you need
to
use an unqualified except clause, unless you import the
extension module, which is presumably supposed to be
opaque (particularly if its identity is variable!)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-18 13:12

Message:
Logged In: YES 
user_id=31435

Assigned to /F.  Would probably be better if, e.g., 
sre_constants.error were a subclass of, say, SyntaxError?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425261&group_id=5470


From noreply@sourceforge.net  Fri May 18 21:43:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 13:43:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-425261 ] re propagates opaque exceptions
Message-ID: <E150r5w-0007Sr-00@usw-sf-web3.sourceforge.net>

Bugs item #425261, was updated on 2001-05-18 10:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425261&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fredrik Lundh (effbot)
Summary: re propagates opaque exceptions

Initial Comment:
If you call re.compile() with an erroneous expression,
the
underlying extension module (pcre, sre, ...?) raises an
exception which is propagated through re to the caller.

In order to catch the exception, it seems that you need
to
use an unqualified except clause, unless you import the
extension module, which is presumably supposed to be
opaque (particularly if its identity is variable!)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-18 13:43

Message:
Logged In: NO 

not a bug.

The "compile" method throws an "error" exception from
the *same* module, no matter what regular expression
module you're using.  This is how it's documented, and
this is how it works.

Or in other words, the following works, whether you've
used "import re", "import sre as re", or "import pre as
re":

   try:
      p = re.compile(...)
   except re.error:
      print "gotcha"

</F>

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 13:12

Message:
Logged In: YES 
user_id=31435

Assigned to /F.  Would probably be better if, e.g., 
sre_constants.error were a subclass of, say, SyntaxError?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425261&group_id=5470


From noreply@sourceforge.net  Fri May 18 21:54:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 13:54:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-425261 ] re propagates opaque exceptions
Message-ID: <E150rGH-0007bm-00@usw-sf-web3.sourceforge.net>

Bugs item #425261, was updated on 2001-05-18 10:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425261&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fredrik Lundh (effbot)
Summary: re propagates opaque exceptions

Initial Comment:
If you call re.compile() with an erroneous expression,
the
underlying extension module (pcre, sre, ...?) raises an
exception which is propagated through re to the caller.

In order to catch the exception, it seems that you need
to
use an unqualified except clause, unless you import the
extension module, which is presumably supposed to be
opaque (particularly if its identity is variable!)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-18 13:54

Message:
Logged In: YES 
user_id=31435

Sounds good to me!  Did you leave this open because you 
thought you were bluffing <wink>?


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-18 13:43

Message:
Logged In: NO 

not a bug.

The "compile" method throws an "error" exception from
the *same* module, no matter what regular expression
module you're using.  This is how it's documented, and
this is how it works.

Or in other words, the following works, whether you've
used "import re", "import sre as re", or "import pre as
re":

   try:
      p = re.compile(...)
   except re.error:
      print "gotcha"

</F>

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 13:12

Message:
Logged In: YES 
user_id=31435

Assigned to /F.  Would probably be better if, e.g., 
sre_constants.error were a subclass of, say, SyntaxError?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425261&group_id=5470


From noreply@sourceforge.net  Fri May 18 22:20:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 14:20:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-425320 ] Typo in introduction.
Message-ID: <E150rfZ-0000uz-00@usw-sf-web2.sourceforge.net>

Bugs item #425320, was updated on 2001-05-18 14:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425320&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Typo in introduction.

Initial Comment:
Paragraph 2, last sentence:

...less straightforward that writing ...

replace "that" with "than".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425320&group_id=5470


From noreply@sourceforge.net  Fri May 18 22:21:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 14:21:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-424776 ] SMTP Example does not work
Message-ID: <E150rh1-0000dq-00@usw-sf-web1.sourceforge.net>

Bugs item #424776, was updated on 2001-05-17 00:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424776&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: SMTP Example does not work

Initial Comment:
Maybe no one tried it for a long time ... the SMTP
example in the 2.1 version of the smtplib part of
'Python Library Reference' uses 'rawinput()' to read
from input. When the 'user' termninates his message
with ^D, rawinput raises EOFError, which is not catched
in this code, which probably should be changed to

while 1:
  try:
    line = raw_input()
  except EOFError:
    break
  msg = msg + line

Regards,
Matthias

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-18 14:21

Message:
Logged In: YES 
user_id=3066

Well, I've fixed this in my sources, but there's stale lock in the CVS repository preventing me from checking this in.  I've filed a support request with SF and will close this bug report when I can make the required checkin.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424776&group_id=5470


From noreply@sourceforge.net  Fri May 18 22:42:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 14:42:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-425325 ] Possible bug in tupleobject.c
Message-ID: <E150s0X-0000zF-00@usw-sf-web1.sourceforge.net>

Bugs item #425325, was updated on 2001-05-18 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Minsk (rminsk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible bug in tupleobject.c

Initial Comment:
While trying to debug a memory corruption problem I may
have run across a problem in Objects/tupleobject.c. 
Line 363 reads:

for (i = o->ob_size; --i >= 0; ) {

Should it be?

for (i = o->ob_size - 1; --i >= 0; ) {

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470


From noreply@sourceforge.net  Fri May 18 22:53:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 14:53:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-425325 ] Possible bug in tupleobject.c
Message-ID: <E150sC5-00019m-00@usw-sf-web1.sourceforge.net>

Bugs item #425325, was updated on 2001-05-18 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 8
Submitted By: Robert Minsk (rminsk)
>Assigned to: Tim Peters (tim_one)
Summary: Possible bug in tupleobject.c

Initial Comment:
While trying to debug a memory corruption problem I may
have run across a problem in Objects/tupleobject.c. 
Line 363 reads:

for (i = o->ob_size; --i >= 0; ) {

Should it be?

for (i = o->ob_size - 1; --i >= 0; ) {

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-18 14:53

Message:
Logged In: YES 
user_id=31435

Zoomed the priority and assigned to me.  Good eye!  The 
same bug appears in listobject.c too.  I'll review all the 
xxx_traverse methods while I'm at it -- cut-&-paste bugs 
are deadly.  Thanks!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470


From noreply@sourceforge.net  Fri May 18 23:07:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 15:07:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-425325 ] Possible bug in tupleobject.c
Message-ID: <E150sOn-0001PC-00@usw-sf-web2.sourceforge.net>

Bugs item #425325, was updated on 2001-05-18 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 8
Submitted By: Robert Minsk (rminsk)
Assigned to: Tim Peters (tim_one)
Summary: Possible bug in tupleobject.c

Initial Comment:
While trying to debug a memory corruption problem I may
have run across a problem in Objects/tupleobject.c. 
Line 363 reads:

for (i = o->ob_size; --i >= 0; ) {

Should it be?

for (i = o->ob_size - 1; --i >= 0; ) {

----------------------------------------------------------------------

>Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 15:07

Message:
Logged In: YES 
user_id=132786

I discovered this using purify.  I am running purify on all
the python test code right now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 14:53

Message:
Logged In: YES 
user_id=31435

Zoomed the priority and assigned to me.  Good eye!  The 
same bug appears in listobject.c too.  I'll review all the 
xxx_traverse methods while I'm at it -- cut-&-paste bugs 
are deadly.  Thanks!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470


From noreply@sourceforge.net  Fri May 18 23:14:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 15:14:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-425325 ] Possible bug in tupleobject.c
Message-ID: <E150sWA-0000DB-00@usw-sf-web3.sourceforge.net>

Bugs item #425325, was updated on 2001-05-18 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: Robert Minsk (rminsk)
Assigned to: Tim Peters (tim_one)
Summary: Possible bug in tupleobject.c

Initial Comment:
While trying to debug a memory corruption problem I may
have run across a problem in Objects/tupleobject.c. 
Line 363 reads:

for (i = o->ob_size; --i >= 0; ) {

Should it be?

for (i = o->ob_size - 1; --i >= 0; ) {

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-18 15:14

Message:
Logged In: YES 
user_id=31435

I'm afraid we're both hallucinating, so reduced the 
priority again.  The  "--i >= 0" is executed before the 
loop begins, so the first value of i is in fact o->ob_size-
1.

So the question shifts to what Purify thinks is wrong.

----------------------------------------------------------------------

Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 15:07

Message:
Logged In: YES 
user_id=132786

I discovered this using purify.  I am running purify on all
the python test code right now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 14:53

Message:
Logged In: YES 
user_id=31435

Zoomed the priority and assigned to me.  Good eye!  The 
same bug appears in listobject.c too.  I'll review all the 
xxx_traverse methods while I'm at it -- cut-&-paste bugs 
are deadly.  Thanks!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470


From noreply@sourceforge.net  Fri May 18 23:53:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 15:53:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-425325 ] Possible bug in tupleobject.c
Message-ID: <E150t88-0000hH-00@usw-sf-web3.sourceforge.net>

Bugs item #425325, was updated on 2001-05-18 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Minsk (rminsk)
Assigned to: Tim Peters (tim_one)
Summary: Possible bug in tupleobject.c

Initial Comment:
While trying to debug a memory corruption problem I may
have run across a problem in Objects/tupleobject.c. 
Line 363 reads:

for (i = o->ob_size; --i >= 0; ) {

Should it be?

for (i = o->ob_size - 1; --i >= 0; ) {

----------------------------------------------------------------------

>Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 15:53

Message:
Logged In: YES 
user_id=132786

Upon futher investigation this may be a bug in the optimizer
from the SGI 7.3.1.2m compilers.  I'm still checking....

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 15:14

Message:
Logged In: YES 
user_id=31435

I'm afraid we're both hallucinating, so reduced the 
priority again.  The  "--i >= 0" is executed before the 
loop begins, so the first value of i is in fact o->ob_size-
1.

So the question shifts to what Purify thinks is wrong.

----------------------------------------------------------------------

Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 15:07

Message:
Logged In: YES 
user_id=132786

I discovered this using purify.  I am running purify on all
the python test code right now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 14:53

Message:
Logged In: YES 
user_id=31435

Zoomed the priority and assigned to me.  Good eye!  The 
same bug appears in listobject.c too.  I'll review all the 
xxx_traverse methods while I'm at it -- cut-&-paste bugs 
are deadly.  Thanks!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470


From noreply@sourceforge.net  Sat May 19 01:24:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 17:24:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-425325 ] Possible bug in tupleobject.c
Message-ID: <E150uXP-0001nZ-00@usw-sf-web3.sourceforge.net>

Bugs item #425325, was updated on 2001-05-18 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Minsk (rminsk)
Assigned to: Tim Peters (tim_one)
Summary: Possible bug in tupleobject.c

Initial Comment:
While trying to debug a memory corruption problem I may
have run across a problem in Objects/tupleobject.c. 
Line 363 reads:

for (i = o->ob_size; --i >= 0; ) {

Should it be?

for (i = o->ob_size - 1; --i >= 0; ) {

----------------------------------------------------------------------

>Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 17:24

Message:
Logged In: YES 
user_id=132786

I just ran the code thru insure++ and you may want to look
at some of the errors...
Some of the 0 size rallocs/mallocs may be causing problems. 
The **FREE_DANGLING** may also be serious.

----------------------------------------------------------------------

Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 15:53

Message:
Logged In: YES 
user_id=132786

Upon futher investigation this may be a bug in the optimizer
from the SGI 7.3.1.2m compilers.  I'm still checking....

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 15:14

Message:
Logged In: YES 
user_id=31435

I'm afraid we're both hallucinating, so reduced the 
priority again.  The  "--i >= 0" is executed before the 
loop begins, so the first value of i is in fact o->ob_size-
1.

So the question shifts to what Purify thinks is wrong.

----------------------------------------------------------------------

Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 15:07

Message:
Logged In: YES 
user_id=132786

I discovered this using purify.  I am running purify on all
the python test code right now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 14:53

Message:
Logged In: YES 
user_id=31435

Zoomed the priority and assigned to me.  Good eye!  The 
same bug appears in listobject.c too.  I'll review all the 
xxx_traverse methods while I'm at it -- cut-&-paste bugs 
are deadly.  Thanks!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470


From noreply@sourceforge.net  Sat May 19 03:19:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 19:19:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-425325 ] Logs from Purify and Insure(?)
Message-ID: <E150wLQ-0005NM-00@usw-sf-web1.sourceforge.net>

Bugs item #425325, was updated on 2001-05-18 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Minsk (rminsk)
>Assigned to: Barry Warsaw (bwarsaw)
>Summary: Logs from Purify and Insure(?)

Initial Comment:
While trying to debug a memory corruption problem I may
have run across a problem in Objects/tupleobject.c. 
Line 363 reads:

for (i = o->ob_size; --i >= 0; ) {

Should it be?

for (i = o->ob_size - 1; --i >= 0; ) {

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-18 19:19

Message:
Logged In: YES 
user_id=31435

Changed "Summary" line to better reflect the current state, 
and reassigned to Barry.

----------------------------------------------------------------------

Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 17:24

Message:
Logged In: YES 
user_id=132786

I just ran the code thru insure++ and you may want to look
at some of the errors...
Some of the 0 size rallocs/mallocs may be causing problems. 
The **FREE_DANGLING** may also be serious.

----------------------------------------------------------------------

Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 15:53

Message:
Logged In: YES 
user_id=132786

Upon futher investigation this may be a bug in the optimizer
from the SGI 7.3.1.2m compilers.  I'm still checking....

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 15:14

Message:
Logged In: YES 
user_id=31435

I'm afraid we're both hallucinating, so reduced the 
priority again.  The  "--i >= 0" is executed before the 
loop begins, so the first value of i is in fact o->ob_size-
1.

So the question shifts to what Purify thinks is wrong.

----------------------------------------------------------------------

Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 15:07

Message:
Logged In: YES 
user_id=132786

I discovered this using purify.  I am running purify on all
the python test code right now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 14:53

Message:
Logged In: YES 
user_id=31435

Zoomed the priority and assigned to me.  Good eye!  The 
same bug appears in listobject.c too.  I'll review all the 
xxx_traverse methods while I'm at it -- cut-&-paste bugs 
are deadly.  Thanks!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470


From noreply@sourceforge.net  Sat May 19 05:28:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 18 May 2001 21:28:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-425370 ] socketmodule SSL free calls in wrong order
Message-ID: <E150yLy-0004aF-00@usw-sf-web3.sourceforge.net>

Bugs item #425370, was updated on 2001-05-18 21:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule SSL free calls in wrong order

Initial Comment:
I was examining socketmodule.c and notice the following ordering of 
allocation and deallocation regarding SSL.

    static SSLObject *
    newSSLObject(PySocketSockObject *Sock, char *key_file, char *cert_file)
    {
        ...
        self->ctx = SSL_CTX_new(SSLv23_method()); /* Set up context */
        ...
        self->ssl = SSL_new(self->ctx); /* New ssl struct */
        ...
    }

    static void SSL_dealloc(SSLObject *self)
    {
        ...
        SSL_CTX_free(self->ctx);
        SSL_free(self->ssl);
        ...
    }

Perhaps it works for now, but I think that the order of free() calls in
SSL_dealloc should be reversed.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470


From noreply@sourceforge.net  Sun May 20 01:16:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 19 May 2001 17:16:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 final broken on Linux!!!
Message-ID: <E151Gtr-0000Ny-00@usw-sf-web1.sourceforge.net>

Bugs item #425007, was updated on 2001-05-17 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 final broken on Linux!!!

Initial Comment:
I have gone back and tried Python 1.6 and 2.0.  Both
work fine.  When I install Python 2.1, everything is
broken.  The problem is that when a module is a shared
library (.so), python refuses to load the module.  Example:

import os
import sys
import SocketServer

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/SocketServer.py", line 126, in ?
    import socket
  File "/usr/lib/python2.1/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket

Now, do a "locate _socket.so" and I get:
/usr/lib/python2.1/site-packages/_socket.so
/usr/lib/python2.1/lib-dynload/_socket.so


Clearly they are there, it's just that Python refuses
to load them.


I made Python 2.1 from source as fetched from the 2.1
tar ball.  It makes cleanly.  During the installation,
I see some items that I believe to be minor that popup,
but don't currectly expect that they are the problem. 
I have tried many times using different configure
options to get this to work, deleting the previous
installation each time.  I've even tried installing in
different locations.

As is, Python 2.1 is completely broken for me.  Surely
I'm not the only one having this problem, especially
since 1.5, 1.6, and 2.0 all work correctly.

Any help would be great.  BTW, doing a "print sys.path"
gives me: ['', '/usr/lib/python2.1',
'/usr/lib/python2.1/plat-linux2',
'/usr/lib/python2.1/lib-tk',
'/usr/lib/python2.1/lib-dynload',
'/usr/lib/python2.1/site-packages']

As you can see, lib-dynload is in the path, so I'm not
really sure what's going on.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-19 17:16

Message:
Logged In: YES 
user_id=149084

Well, import SocketServer works ok for me with Python built
both from the 2.1 tar file and the 2.2a0 CVS tree. I'm
running Linux 2.2.5 (RH 6.2) on Pentium.

Did you make clean after changing the configure options?

It is not normal to have _socket.so in .../site-packages; it
should be only in .../lib-dynload.  Default installation has
only the README file in site-packages.

Your sys.path looks normal, except that Python default
installs at /usr/local/[bin/lib].  I tried a build targeted
at /usr/[bin/lib] and it was ok.

You could try make clobber, but it's almost as fast to start
over. Try a vanilla installation:
1. delete your install tree @ /usr/local/lib/python2.1
(and/or /usr/lib)
2. delete your source tree from wherever you unpacked the
tar file.
3. untar again, cd to source directory it created
4. without changing any files, and no configure options, run
./configure, then make, then make install

If that doesn't help, what Linux are you running, on what
box, and where did you get your 2.1 tar file?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470


From noreply@sourceforge.net  Sun May 20 14:36:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 20 May 2001 06:36:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-424776 ] SMTP Example does not work
Message-ID: <E151TNl-0003n7-00@usw-sf-web1.sourceforge.net>

Bugs item #424776, was updated on 2001-05-17 00:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424776&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: SMTP Example does not work

Initial Comment:
Maybe no one tried it for a long time ... the SMTP
example in the 2.1 version of the smtplib part of
'Python Library Reference' uses 'rawinput()' to read
from input. When the 'user' termninates his message
with ^D, rawinput raises EOFError, which is not catched
in this code, which probably should be changed to

while 1:
  try:
    line = raw_input()
  except EOFError:
    break
  msg = msg + line

Regards,
Matthias

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-20 06:36

Message:
Logged In: YES 
user_id=3066

Checked in as Doc/lib/libsmtplib.tex revisions 1.17 and 1.16.6.1.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-18 14:21

Message:
Logged In: YES 
user_id=3066

Well, I've fixed this in my sources, but there's stale lock in the CVS repository preventing me from checking this in.  I've filed a support request with SF and will close this bug report when I can make the required checkin.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424776&group_id=5470


From noreply@sourceforge.net  Sun May 20 18:35:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 20 May 2001 10:35:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 final broken on Linux!!!
Message-ID: <E151X7I-0006Iy-00@usw-sf-web3.sourceforge.net>

Bugs item #425007, was updated on 2001-05-17 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 final broken on Linux!!!

Initial Comment:
I have gone back and tried Python 1.6 and 2.0.  Both
work fine.  When I install Python 2.1, everything is
broken.  The problem is that when a module is a shared
library (.so), python refuses to load the module.  Example:

import os
import sys
import SocketServer

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/SocketServer.py", line 126, in ?
    import socket
  File "/usr/lib/python2.1/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket

Now, do a "locate _socket.so" and I get:
/usr/lib/python2.1/site-packages/_socket.so
/usr/lib/python2.1/lib-dynload/_socket.so


Clearly they are there, it's just that Python refuses
to load them.


I made Python 2.1 from source as fetched from the 2.1
tar ball.  It makes cleanly.  During the installation,
I see some items that I believe to be minor that popup,
but don't currectly expect that they are the problem. 
I have tried many times using different configure
options to get this to work, deleting the previous
installation each time.  I've even tried installing in
different locations.

As is, Python 2.1 is completely broken for me.  Surely
I'm not the only one having this problem, especially
since 1.5, 1.6, and 2.0 all work correctly.

Any help would be great.  BTW, doing a "print sys.path"
gives me: ['', '/usr/lib/python2.1',
'/usr/lib/python2.1/plat-linux2',
'/usr/lib/python2.1/lib-tk',
'/usr/lib/python2.1/lib-dynload',
'/usr/lib/python2.1/site-packages']

As you can see, lib-dynload is in the path, so I'm not
really sure what's going on.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-20 10:35

Message:
Logged In: YES 
user_id=6380

Clearly it's something you have done to yourself. :-)  The
question is how to find out what.

Try "python -v" or even "python -vv" and see what it prints
when you try to import _socket. This should give you some
clues (it shows where it searches for modules during
import).

As kbk says, that other _socket.so is mysterious.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-19 17:16

Message:
Logged In: YES 
user_id=149084

Well, import SocketServer works ok for me with Python built
both from the 2.1 tar file and the 2.2a0 CVS tree. I'm
running Linux 2.2.5 (RH 6.2) on Pentium.

Did you make clean after changing the configure options?

It is not normal to have _socket.so in .../site-packages; it
should be only in .../lib-dynload.  Default installation has
only the README file in site-packages.

Your sys.path looks normal, except that Python default
installs at /usr/local/[bin/lib].  I tried a build targeted
at /usr/[bin/lib] and it was ok.

You could try make clobber, but it's almost as fast to start
over. Try a vanilla installation:
1. delete your install tree @ /usr/local/lib/python2.1
(and/or /usr/lib)
2. delete your source tree from wherever you unpacked the
tar file.
3. untar again, cd to source directory it created
4. without changing any files, and no configure options, run
./configure, then make, then make install

If that doesn't help, what Linux are you running, on what
box, and where did you get your 2.1 tar file?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470


From noreply@sourceforge.net  Sun May 20 20:06:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 20 May 2001 12:06:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E151YXJ-0007Pd-00@usw-sf-web3.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-20 12:06

Message:
Logged In: YES 
user_id=198402

Well I was wrong. We do need a "try" block to ensure the 
request is always correctly closed:

    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        try:
            self.RequestHandlerClass(request, 
client_address, self)
        finally:
            self.close_request(request)

This works better.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-13 09:09

Message:
Logged In: YES 
user_id=198402

I forgot to tell: I can not test if it does not break the 
forking server. I only have a windows platform available 
for now, and forking doesn't work in the python/win32 
environment for now as far as I know.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-13 08:51

Message:
Logged In: YES 
user_id=198402

What I propose can be applied without any compatibility 
issue.

I have tried something that seems to work, at least under 
windows (but it does need to be more fully tested though). 
Only 2 small modifications are required:

-1- In BaseServer, modification of the last line of 
handle_request:
<PRE>
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)

</PRE>
Note that only the indentation of the last has been 
modified so that the close_request is executed only if an 
exception occur.

Still we need to close the request after it had been 
processed, so here comes the second modification:
-2- Still in BaseServer:
<PRE>
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
</PRE>

There is already a try/except block in handle_request, so I 
thought it was not mandatory here to ensure the request was 
always closed.

Oh... I don't know how &lt;PRE&gt; tags are supported by 
the bugtracking system of sourceforge, so the samples I 
give may not appear as I want. This is quite a problem with 
python :/

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-12 15:46

Message:
Logged In: YES 
user_id=80200

hi there mr xlagraula,

yes, it would be a lot simpler... _if_ it wasn't
for the fact that this code is likely to already
be quite extensively used.  a possible 'upgrade'
path could be done by providing a... RequestHandler2
class, or some-such.

it would be neater to do this, or similar:
for t in self.thread_list:
    t.join(timeout=0.1)

which would join all threads, or you do if
stopped(), close_request.  i looked into
threads a bit more: join has a timeout,
and there is a stopped-detection function.

easy :)

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-12 14:18

Message:
Logged In: YES 
user_id=198402

Another solution could be to modify the behaviour of the 
server so that it would be the responsibility of 
the "child" thread/process to close the socket (except for 
the forking/threading error cases). Wouldn't it be simplier 
than child process tracking and thread tracking?

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-04 04:17

Message:
Logged In: YES 
user_id=80200

okay.  the forkingmixin code does a fork, records how many
children there are, and waits for one of them to exit,
before
proceeding - in particular, before proceeding to close
the request, etc.

... so why is not something similar done in ThreadingMixIn?

this kinda- tells me that thread-tracking is really needed,
in a similar way to that in forkingmixin.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2001-05-03 16:26

Message:
Logged In: YES 
user_id=413

Just a note of another casualty of this bug: I had to add
the mentioned dummy close_request method hack to our own
ThreadingMixIn class in mojo nation (in the sourceforge
mojonation project's evil module, see the
common/MojoNationHTTPServer.py file).  Without it, python
2.1 would always raise an exception in the request handler
as soon as it tried to call self.connection.makefile()
because self.connection had apparently already been closed! 
(its fd was always -1)


----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-02 01:41

Message:
Logged In: YES 
user_id=80200

hi there mr jrielh,

thank you very much for the details.  what i am having a
little difficulty with is, what's the difference between
this and python 2.0 SocketServer.py?

more specifically, i'm looking at python 2.0 SocketServer.py
and, whilst i'm not a Threads expert, i see a t.start() but
no t.join().  i've been looking at the Queue example code in
the test method of threads.py, and start() is called on
every thread, followed by join() on every thread.  join
waits for the thread to finish, yes?

so... if that's the case, then python 2.0 SocketServer.py
should suffer from
exactly the same behaviour, yes?  unless python behaves
ever-so-slightly differently (timing issues?) when you have
an extra base class like this,
with the consequence that close_request() is more likely to
be called
before ThreadingMixIn.process_request().

?

----------------------------------------------------------------------

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:20

Message:
Logged In: YES 
user_id=22448

This is related to bug #419873.
The problem is not specifically in the ThreadingMixin
specifically, but where BaseServer calls close_request()
after calling process_request().  In the threading mixin,
process_request() spins the thread and returns, causing the
request socket to be invalidated while the thread is still
running.  The fix given above will keep the socket valid
while the thread is running, but may cause the socket to not
close properly (my threads generally close the socket when
they are done anyway.)

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470


From noreply@sourceforge.net  Mon May 21 08:37:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 00:37:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-425836 ] Reference leak in filter()
Message-ID: <E151kG5-0004mu-00@usw-sf-web1.sourceforge.net>

Bugs item #425836, was updated on 2001-05-21 00:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425836&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Tim Peters (tim_one)
Summary: Reference leak in filter()

Initial Comment:
I appear to have struck a reference leak in filter:

>>> l=range(10)
[5552 refs]
>>> l2=filter(lambda m:m, l)
[5571 refs]
>>> l2=filter(lambda m:m, l)
[5574 refs]

etc - always dropping 3 references.

The following patch fixes it:

Index: bltinmodule.c
=======================================================
============
RCS 
file: /cvsroot/python/python/dist/src/Python/bltinmodul
e.c,v
retrieving revision 2.207
diff -c -r2.207 bltinmodule.c
*** bltinmodule.c	2001/05/14 12:17:34	2.207
--- bltinmodule.c	2001/05/21 07:37:07
***************
*** 264,269 ****
--- 264,270 ----
  	if (j < len && PyList_SetSlice(result, j, len, 
NULL) < 0)
  		goto Fail_result_it;
  
+ 	Py_DECREF(it);
  	return result;
  
  Fail_result_it:




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425836&group_id=5470


From noreply@sourceforge.net  Mon May 21 09:08:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 01:08:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-425836 ] Reference leak in filter()
Message-ID: <E151kjy-0008AH-00@usw-sf-web3.sourceforge.net>

Bugs item #425836, was updated on 2001-05-21 00:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425836&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Tim Peters (tim_one)
Summary: Reference leak in filter()

Initial Comment:
I appear to have struck a reference leak in filter:

>>> l=range(10)
[5552 refs]
>>> l2=filter(lambda m:m, l)
[5571 refs]
>>> l2=filter(lambda m:m, l)
[5574 refs]

etc - always dropping 3 references.

The following patch fixes it:

Index: bltinmodule.c
=======================================================
============
RCS 
file: /cvsroot/python/python/dist/src/Python/bltinmodul
e.c,v
retrieving revision 2.207
diff -c -r2.207 bltinmodule.c
*** bltinmodule.c	2001/05/14 12:17:34	2.207
--- bltinmodule.c	2001/05/21 07:37:07
***************
*** 264,269 ****
--- 264,270 ----
  	if (j < len && PyList_SetSlice(result, j, len, 
NULL) < 0)
  		goto Fail_result_it;
  
+ 	Py_DECREF(it);
  	return result;
  
  Fail_result_it:




----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-21 01:08

Message:
Logged In: YES 
user_id=31435

So don't use filter <wink>.

Oh, all right, it's a bug.  Thanks for enduring the pain!
Checked in as Python/bltinmodule.c, new revision: 2.208.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425836&group_id=5470


From noreply@sourceforge.net  Mon May 21 10:46:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 02:46:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Unicode Build Prob.
Message-ID: <E151mGb-0000yV-00@usw-sf-web3.sourceforge.net>

Bugs item #420416, was updated on 2001-05-01 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Schinckel (schinckel)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Python for BeOS/PPC Unicode Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 02:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 04:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470


From noreply@sourceforge.net  Mon May 21 11:09:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 03:09:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-425868 ] mimify.mime_encode_header problem
Message-ID: <E151mdJ-0001GT-00@usw-sf-web3.sourceforge.net>

Bugs item #425868, was updated on 2001-05-21 03:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425868&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: mimify.mime_encode_header problem

Initial Comment:
Within the standard-module mimify.py, the function 
mime_encode_header does not work RFC2047-compliant (in 
fact, it does not work for me at all).

Please take a look at the following interactive 
session:
--------
Python 2.1 (#8, May  4 2001, 12:40:12)
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more 
information.
>>> import mimify
>>> print mimify.mime_encode_header("Subject: äöüß 
äöüß Test  äöüß\n")
Subject: =?ISO-8859-1?Q?=E4=F6=FC=DF?= äöüß Test  =?
ISO-8859-1?Q?=E4=F6=FC=DF?=
--------

As you can see, the second word with 8-bit characters 
has not been encoded at all. Only because there are 
two spaces behind "Test" the last word has been 
encoded.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425868&group_id=5470


From noreply@sourceforge.net  Mon May 21 16:04:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 08:04:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-425320 ] Typo in introduction.
Message-ID: <E151rEu-0007tB-00@usw-sf-web2.sourceforge.net>

Bugs item #425320, was updated on 2001-05-18 14:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425320&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Typo in introduction.

Initial Comment:
Paragraph 2, last sentence:

...less straightforward that writing ...

replace "that" with "than".

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-21 08:04

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/api/api.tex revisions 1.122 and 1.117.2.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425320&group_id=5470


From noreply@sourceforge.net  Mon May 21 16:13:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 08:13:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 final broken on Linux!!!
Message-ID: <E151rN2-0005PA-00@usw-sf-web3.sourceforge.net>

Bugs item #425007, was updated on 2001-05-17 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.1 final broken on Linux!!!

Initial Comment:
I have gone back and tried Python 1.6 and 2.0.  Both
work fine.  When I install Python 2.1, everything is
broken.  The problem is that when a module is a shared
library (.so), python refuses to load the module.  Example:

import os
import sys
import SocketServer

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/SocketServer.py", line 126, in ?
    import socket
  File "/usr/lib/python2.1/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket

Now, do a "locate _socket.so" and I get:
/usr/lib/python2.1/site-packages/_socket.so
/usr/lib/python2.1/lib-dynload/_socket.so


Clearly they are there, it's just that Python refuses
to load them.


I made Python 2.1 from source as fetched from the 2.1
tar ball.  It makes cleanly.  During the installation,
I see some items that I believe to be minor that popup,
but don't currectly expect that they are the problem. 
I have tried many times using different configure
options to get this to work, deleting the previous
installation each time.  I've even tried installing in
different locations.

As is, Python 2.1 is completely broken for me.  Surely
I'm not the only one having this problem, especially
since 1.5, 1.6, and 2.0 all work correctly.

Any help would be great.  BTW, doing a "print sys.path"
gives me: ['', '/usr/lib/python2.1',
'/usr/lib/python2.1/plat-linux2',
'/usr/lib/python2.1/lib-tk',
'/usr/lib/python2.1/lib-dynload',
'/usr/lib/python2.1/site-packages']

As you can see, lib-dynload is in the path, so I'm not
really sure what's going on.

----------------------------------------------------------------------

Comment By: Greg Copeland (oracle)
Date: 2001-05-21 08:13

Message:
Logged In: YES 
user_id=40173

The problem is that the installation is partially broken. It
didn't install the shared libraries with proper permissions.
When Python installed the shared libs, it installed the libs
as root.root having 0700 permissions. When I tried to
execute it as a normal user, obviously, it fails to load the
shared lib. Python then, incorrectly reports that the shared
lib can not be found.  Of course, the correct solution is
for Python to accurately report the problem and to have the
installation always install the libraries with correct
ownership and permission.  I don't think I'm asking for too
much here.  Seems pretty reasonable to me.

Anyone stating that I did not install correctly is woefully
incorrect. Simply put, the installation is not 100%. As for
some of the libraries existing twice. Well, simply put, the
installation is not 100%.

At any rate, I think it's safe to close this bug but we
might want to add it to the faq-o-matic somewhere or some
such thing.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-20 10:35

Message:
Logged In: YES 
user_id=6380

Clearly it's something you have done to yourself. :-)  The
question is how to find out what.

Try "python -v" or even "python -vv" and see what it prints
when you try to import _socket. This should give you some
clues (it shows where it searches for modules during
import).

As kbk says, that other _socket.so is mysterious.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-19 17:16

Message:
Logged In: YES 
user_id=149084

Well, import SocketServer works ok for me with Python built
both from the 2.1 tar file and the 2.2a0 CVS tree. I'm
running Linux 2.2.5 (RH 6.2) on Pentium.

Did you make clean after changing the configure options?

It is not normal to have _socket.so in .../site-packages; it
should be only in .../lib-dynload.  Default installation has
only the README file in site-packages.

Your sys.path looks normal, except that Python default
installs at /usr/local/[bin/lib].  I tried a build targeted
at /usr/[bin/lib] and it was ok.

You could try make clobber, but it's almost as fast to start
over. Try a vanilla installation:
1. delete your install tree @ /usr/local/lib/python2.1
(and/or /usr/lib)
2. delete your source tree from wherever you unpacked the
tar file.
3. untar again, cd to source directory it created
4. without changing any files, and no configure options, run
./configure, then make, then make install

If that doesn't help, what Linux are you running, on what
box, and where did you get your 2.1 tar file?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470


From noreply@sourceforge.net  Mon May 21 17:57:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 09:57:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-424552 ] Example function # 4.4 is incorrect
Message-ID: <E151szT-0005u8-00@usw-sf-web1.sourceforge.net>

Bugs item #424552, was updated on 2001-05-16 08:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424552&group_id=5470

Category: Documentation
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Example function # 4.4 is incorrect

Initial Comment:
(Refers to the online tutorial at 
http://www.python.org/doc/current/tut/node6.html#SECTIO
N006400000000000000000)

The code should be changed to:

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...             print n, 'equals', x, '*', n/x
...             break 
...         elif x < (n-1) :
...             continue # keep checking
...         else:
...             print n, 'is a prime number'



Otherwise, you will get multiple "7 is a prime number" 
statements with the current code. Also, if would 
incorrectly say "9 is a prime number" and "9 equals 3 
* 3". I added the elif/continue part to take care of 
these two problems.



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-21 09:57

Message:
Logged In: YES 
user_id=3066

Checked in as part of Doc/tut/tut.tex revision 1.135.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-16 08:41

Message:
Logged In: YES 
user_id=3066

I'll add a comment to the "else" clause of the for loop in  a future checkin, but the code is correct.

(The submitter admitted he made an indentation error in a followup email.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424552&group_id=5470


From noreply@sourceforge.net  Mon May 21 18:03:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 10:03:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-419434 ] Tutorial contains wrong sample code.
Message-ID: <E151t62-00061t-00@usw-sf-web1.sourceforge.net>

Bugs item #419434, was updated on 2001-04-27 02:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419434&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dinu C. Gherman (dinu_gherman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tutorial contains wrong sample code.

Initial Comment:
The tutorial for version 2.1 of Python contains this piece of wrong code:

>>> x = 10 * 3.14
>>> y = 200*200
>>> s = 'The value of x is ' + `x` + ', and y is ' + `y` + '...'
>>> print s
The value of x is 31.4, and y is 40000...

where the real output should read:

>>> print s
The value of x is 31.400000000000002, and y is 40000...

Dinu Gherman


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-21 10:03

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/tut/tut.tex revisions 1.135 and 1.133.2.2.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=419434&group_id=5470


From noreply@sourceforge.net  Mon May 21 20:24:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 12:24:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 installs shared libs with mode 0700
Message-ID: <E151vIR-0008R5-00@usw-sf-web1.sourceforge.net>

Bugs item #425007, was updated on 2001-05-17 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Python 2.1 installs shared libs with mode 0700

Initial Comment:
I have gone back and tried Python 1.6 and 2.0.  Both
work fine.  When I install Python 2.1, everything is
broken.  The problem is that when a module is a shared
library (.so), python refuses to load the module.  Example:

import os
import sys
import SocketServer

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/SocketServer.py", line 126, in ?
    import socket
  File "/usr/lib/python2.1/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket

Now, do a "locate _socket.so" and I get:
/usr/lib/python2.1/site-packages/_socket.so
/usr/lib/python2.1/lib-dynload/_socket.so


Clearly they are there, it's just that Python refuses
to load them.


I made Python 2.1 from source as fetched from the 2.1
tar ball.  It makes cleanly.  During the installation,
I see some items that I believe to be minor that popup,
but don't currectly expect that they are the problem. 
I have tried many times using different configure
options to get this to work, deleting the previous
installation each time.  I've even tried installing in
different locations.

As is, Python 2.1 is completely broken for me.  Surely
I'm not the only one having this problem, especially
since 1.5, 1.6, and 2.0 all work correctly.

Any help would be great.  BTW, doing a "print sys.path"
gives me: ['', '/usr/lib/python2.1',
'/usr/lib/python2.1/plat-linux2',
'/usr/lib/python2.1/lib-tk',
'/usr/lib/python2.1/lib-dynload',
'/usr/lib/python2.1/site-packages']

As you can see, lib-dynload is in the path, so I'm not
really sure what's going on.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:24

Message:
Logged In: YES 
user_id=6380

I didn't mean to imply that you did something incorrectly. 
I just meant that there was some interaction between your
system and Python that didn't work out the way it was
supposed to be. Since Python installs correctly on most
systems, I was implying that there's something unusual in
your system that the Python install procedure doesn't
anticipate.

The mode 0700 for the shared libraries is a big hint at what
was wrong (and if you had done an ls -l of the file when
first reporting this we would have figured out the problem
much quicker). Is perhaps the umask of the user who built
(not installed) the files set to 077? In that case, the
cause is that the "make install" by root doesn't change the
file modes to something more reasonable (I've confirmed that
this indeed happens). I'll look into whether this can be
fixed. I'm changing the subject line of this bug report to
reflect more accurately that the problem is with the file
modes of shared libs.

I still believe that the _socket.so in site-packages could
not have been placed there by the normal Python install
procedure.


----------------------------------------------------------------------

Comment By: Greg Copeland (oracle)
Date: 2001-05-21 08:13

Message:
Logged In: YES 
user_id=40173

The problem is that the installation is partially broken. It
didn't install the shared libraries with proper permissions.
When Python installed the shared libs, it installed the libs
as root.root having 0700 permissions. When I tried to
execute it as a normal user, obviously, it fails to load the
shared lib. Python then, incorrectly reports that the shared
lib can not be found.  Of course, the correct solution is
for Python to accurately report the problem and to have the
installation always install the libraries with correct
ownership and permission.  I don't think I'm asking for too
much here.  Seems pretty reasonable to me.

Anyone stating that I did not install correctly is woefully
incorrect. Simply put, the installation is not 100%. As for
some of the libraries existing twice. Well, simply put, the
installation is not 100%.

At any rate, I think it's safe to close this bug but we
might want to add it to the faq-o-matic somewhere or some
such thing.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-20 10:35

Message:
Logged In: YES 
user_id=6380

Clearly it's something you have done to yourself. :-)  The
question is how to find out what.

Try "python -v" or even "python -vv" and see what it prints
when you try to import _socket. This should give you some
clues (it shows where it searches for modules during
import).

As kbk says, that other _socket.so is mysterious.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-19 17:16

Message:
Logged In: YES 
user_id=149084

Well, import SocketServer works ok for me with Python built
both from the 2.1 tar file and the 2.2a0 CVS tree. I'm
running Linux 2.2.5 (RH 6.2) on Pentium.

Did you make clean after changing the configure options?

It is not normal to have _socket.so in .../site-packages; it
should be only in .../lib-dynload.  Default installation has
only the README file in site-packages.

Your sys.path looks normal, except that Python default
installs at /usr/local/[bin/lib].  I tried a build targeted
at /usr/[bin/lib] and it was ok.

You could try make clobber, but it's almost as fast to start
over. Try a vanilla installation:
1. delete your install tree @ /usr/local/lib/python2.1
(and/or /usr/lib)
2. delete your source tree from wherever you unpacked the
tar file.
3. untar again, cd to source directory it created
4. without changing any files, and no configure options, run
./configure, then make, then make install

If that doesn't help, what Linux are you running, on what
box, and where did you get your 2.1 tar file?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470


From noreply@sourceforge.net  Mon May 21 20:32:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 12:32:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 installs shared libs with mode 0700
Message-ID: <E151vPU-0002jo-00@usw-sf-web2.sourceforge.net>

Bugs item #425007, was updated on 2001-05-17 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Python 2.1 installs shared libs with mode 0700

Initial Comment:
I have gone back and tried Python 1.6 and 2.0.  Both
work fine.  When I install Python 2.1, everything is
broken.  The problem is that when a module is a shared
library (.so), python refuses to load the module.  Example:

import os
import sys
import SocketServer

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/SocketServer.py", line 126, in ?
    import socket
  File "/usr/lib/python2.1/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket

Now, do a "locate _socket.so" and I get:
/usr/lib/python2.1/site-packages/_socket.so
/usr/lib/python2.1/lib-dynload/_socket.so


Clearly they are there, it's just that Python refuses
to load them.


I made Python 2.1 from source as fetched from the 2.1
tar ball.  It makes cleanly.  During the installation,
I see some items that I believe to be minor that popup,
but don't currectly expect that they are the problem. 
I have tried many times using different configure
options to get this to work, deleting the previous
installation each time.  I've even tried installing in
different locations.

As is, Python 2.1 is completely broken for me.  Surely
I'm not the only one having this problem, especially
since 1.5, 1.6, and 2.0 all work correctly.

Any help would be great.  BTW, doing a "print sys.path"
gives me: ['', '/usr/lib/python2.1',
'/usr/lib/python2.1/plat-linux2',
'/usr/lib/python2.1/lib-tk',
'/usr/lib/python2.1/lib-dynload',
'/usr/lib/python2.1/site-packages']

As you can see, lib-dynload is in the path, so I'm not
really sure what's going on.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:32

Message:
Logged In: YES 
user_id=6380

Assigning this to Andrew -- clearly the setup.py script (or
distutils) needs to be fixed to fix this.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:24

Message:
Logged In: YES 
user_id=6380

I didn't mean to imply that you did something incorrectly. 
I just meant that there was some interaction between your
system and Python that didn't work out the way it was
supposed to be. Since Python installs correctly on most
systems, I was implying that there's something unusual in
your system that the Python install procedure doesn't
anticipate.

The mode 0700 for the shared libraries is a big hint at what
was wrong (and if you had done an ls -l of the file when
first reporting this we would have figured out the problem
much quicker). Is perhaps the umask of the user who built
(not installed) the files set to 077? In that case, the
cause is that the "make install" by root doesn't change the
file modes to something more reasonable (I've confirmed that
this indeed happens). I'll look into whether this can be
fixed. I'm changing the subject line of this bug report to
reflect more accurately that the problem is with the file
modes of shared libs.

I still believe that the _socket.so in site-packages could
not have been placed there by the normal Python install
procedure.


----------------------------------------------------------------------

Comment By: Greg Copeland (oracle)
Date: 2001-05-21 08:13

Message:
Logged In: YES 
user_id=40173

The problem is that the installation is partially broken. It
didn't install the shared libraries with proper permissions.
When Python installed the shared libs, it installed the libs
as root.root having 0700 permissions. When I tried to
execute it as a normal user, obviously, it fails to load the
shared lib. Python then, incorrectly reports that the shared
lib can not be found.  Of course, the correct solution is
for Python to accurately report the problem and to have the
installation always install the libraries with correct
ownership and permission.  I don't think I'm asking for too
much here.  Seems pretty reasonable to me.

Anyone stating that I did not install correctly is woefully
incorrect. Simply put, the installation is not 100%. As for
some of the libraries existing twice. Well, simply put, the
installation is not 100%.

At any rate, I think it's safe to close this bug but we
might want to add it to the faq-o-matic somewhere or some
such thing.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-20 10:35

Message:
Logged In: YES 
user_id=6380

Clearly it's something you have done to yourself. :-)  The
question is how to find out what.

Try "python -v" or even "python -vv" and see what it prints
when you try to import _socket. This should give you some
clues (it shows where it searches for modules during
import).

As kbk says, that other _socket.so is mysterious.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-19 17:16

Message:
Logged In: YES 
user_id=149084

Well, import SocketServer works ok for me with Python built
both from the 2.1 tar file and the 2.2a0 CVS tree. I'm
running Linux 2.2.5 (RH 6.2) on Pentium.

Did you make clean after changing the configure options?

It is not normal to have _socket.so in .../site-packages; it
should be only in .../lib-dynload.  Default installation has
only the README file in site-packages.

Your sys.path looks normal, except that Python default
installs at /usr/local/[bin/lib].  I tried a build targeted
at /usr/[bin/lib] and it was ok.

You could try make clobber, but it's almost as fast to start
over. Try a vanilla installation:
1. delete your install tree @ /usr/local/lib/python2.1
(and/or /usr/lib)
2. delete your source tree from wherever you unpacked the
tar file.
3. untar again, cd to source directory it created
4. without changing any files, and no configure options, run
./configure, then make, then make install

If that doesn't help, what Linux are you running, on what
box, and where did you get your 2.1 tar file?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470


From noreply@sourceforge.net  Mon May 21 21:15:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 13:15:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 installs shared libs with mode 0700
Message-ID: <E151w50-0003EW-00@usw-sf-web2.sourceforge.net>

Bugs item #425007, was updated on 2001-05-17 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470

>Category: Distutils
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: A.M. Kuchling (akuchling)
Summary: Python 2.1 installs shared libs with mode 0700

Initial Comment:
I have gone back and tried Python 1.6 and 2.0.  Both
work fine.  When I install Python 2.1, everything is
broken.  The problem is that when a module is a shared
library (.so), python refuses to load the module.  Example:

import os
import sys
import SocketServer

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/SocketServer.py", line 126, in ?
    import socket
  File "/usr/lib/python2.1/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket

Now, do a "locate _socket.so" and I get:
/usr/lib/python2.1/site-packages/_socket.so
/usr/lib/python2.1/lib-dynload/_socket.so


Clearly they are there, it's just that Python refuses
to load them.


I made Python 2.1 from source as fetched from the 2.1
tar ball.  It makes cleanly.  During the installation,
I see some items that I believe to be minor that popup,
but don't currectly expect that they are the problem. 
I have tried many times using different configure
options to get this to work, deleting the previous
installation each time.  I've even tried installing in
different locations.

As is, Python 2.1 is completely broken for me.  Surely
I'm not the only one having this problem, especially
since 1.5, 1.6, and 2.0 all work correctly.

Any help would be great.  BTW, doing a "print sys.path"
gives me: ['', '/usr/lib/python2.1',
'/usr/lib/python2.1/plat-linux2',
'/usr/lib/python2.1/lib-tk',
'/usr/lib/python2.1/lib-dynload',
'/usr/lib/python2.1/site-packages']

As you can see, lib-dynload is in the path, so I'm not
really sure what's going on.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:15

Message:
Logged In: YES 
user_id=11375

Reclassifying as a Distutils bug.  

The install_lib subcommand simply copies the contents of 
the BUILD/ tree.  It needs to pointedly ignore the umask 
and set the proper permissions on the installed files.
  


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:32

Message:
Logged In: YES 
user_id=6380

Assigning this to Andrew -- clearly the setup.py script (or
distutils) needs to be fixed to fix this.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:24

Message:
Logged In: YES 
user_id=6380

I didn't mean to imply that you did something incorrectly. 
I just meant that there was some interaction between your
system and Python that didn't work out the way it was
supposed to be. Since Python installs correctly on most
systems, I was implying that there's something unusual in
your system that the Python install procedure doesn't
anticipate.

The mode 0700 for the shared libraries is a big hint at what
was wrong (and if you had done an ls -l of the file when
first reporting this we would have figured out the problem
much quicker). Is perhaps the umask of the user who built
(not installed) the files set to 077? In that case, the
cause is that the "make install" by root doesn't change the
file modes to something more reasonable (I've confirmed that
this indeed happens). I'll look into whether this can be
fixed. I'm changing the subject line of this bug report to
reflect more accurately that the problem is with the file
modes of shared libs.

I still believe that the _socket.so in site-packages could
not have been placed there by the normal Python install
procedure.


----------------------------------------------------------------------

Comment By: Greg Copeland (oracle)
Date: 2001-05-21 08:13

Message:
Logged In: YES 
user_id=40173

The problem is that the installation is partially broken. It
didn't install the shared libraries with proper permissions.
When Python installed the shared libs, it installed the libs
as root.root having 0700 permissions. When I tried to
execute it as a normal user, obviously, it fails to load the
shared lib. Python then, incorrectly reports that the shared
lib can not be found.  Of course, the correct solution is
for Python to accurately report the problem and to have the
installation always install the libraries with correct
ownership and permission.  I don't think I'm asking for too
much here.  Seems pretty reasonable to me.

Anyone stating that I did not install correctly is woefully
incorrect. Simply put, the installation is not 100%. As for
some of the libraries existing twice. Well, simply put, the
installation is not 100%.

At any rate, I think it's safe to close this bug but we
might want to add it to the faq-o-matic somewhere or some
such thing.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-20 10:35

Message:
Logged In: YES 
user_id=6380

Clearly it's something you have done to yourself. :-)  The
question is how to find out what.

Try "python -v" or even "python -vv" and see what it prints
when you try to import _socket. This should give you some
clues (it shows where it searches for modules during
import).

As kbk says, that other _socket.so is mysterious.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-19 17:16

Message:
Logged In: YES 
user_id=149084

Well, import SocketServer works ok for me with Python built
both from the 2.1 tar file and the 2.2a0 CVS tree. I'm
running Linux 2.2.5 (RH 6.2) on Pentium.

Did you make clean after changing the configure options?

It is not normal to have _socket.so in .../site-packages; it
should be only in .../lib-dynload.  Default installation has
only the README file in site-packages.

Your sys.path looks normal, except that Python default
installs at /usr/local/[bin/lib].  I tried a build targeted
at /usr/[bin/lib] and it was ok.

You could try make clobber, but it's almost as fast to start
over. Try a vanilla installation:
1. delete your install tree @ /usr/local/lib/python2.1
(and/or /usr/lib)
2. delete your source tree from wherever you unpacked the
tar file.
3. untar again, cd to source directory it created
4. without changing any files, and no configure options, run
./configure, then make, then make install

If that doesn't help, what Linux are you running, on what
box, and where did you get your 2.1 tar file?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470


From noreply@sourceforge.net  Mon May 21 21:29:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 13:29:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-232619 ] 2.1a2 misleading comment from "make install" (minor nit)
Message-ID: <E151wJF-0001K9-00@usw-sf-web3.sourceforge.net>

Bugs item #232619, was updated on 2001-02-15 14:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232619&group_id=5470

Category: Installation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Favas (mfavas)
Assigned to: A.M. Kuchling (akuchling)
>Summary: 2.1a2 misleading comment from "make install" (minor nit)

Initial Comment:
Towards the end of the output from "make install" (using current - Feb 16 - CVS) appears the following:

warning: install: modules installed to '/usr/local/lib/python2.1/lib-dynload/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself

This is misleading, as /usr/local/lib/python2.1/lib-dynload is indeed in the newly installed python's sys.path - just not in the sys.path of the just-built-but-not-installed python.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:29

Message:
Logged In: YES 
user_id=11375

Fixed in revision 1.39 of setup.py.


----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-13 18:53

Message:
Logged In: YES 
user_id=149084

Patch 423830 Submitted

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-28 11:30

Message:
Logged In: YES 
user_id=3066

Andrew, this looks related to the move to distutils for building the standard library extension modules.  Can you handle it please?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232619&group_id=5470


From noreply@sourceforge.net  Mon May 21 21:35:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 13:35:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-418369 ] Typo in distutils (1.5 and 2.1)
Message-ID: <E151wON-0001Gp-00@usw-sf-web1.sourceforge.net>

Bugs item #418369, was updated on 2001-04-23 14:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418369&group_id=5470

Category: Distutils
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: A.M. Kuchling (akuchling)
Summary: Typo in distutils (1.5 and 2.1)

Initial Comment:
If README or README.txt are not specified in
doc_files, then bdist_rpm attempts to locate them. If
they exist, bdist_rpm adds them, erroneously, to
self.doc, instead of (correctly) to self.doc_files

self.doc does not exists, which then throws an
AttributeError

The offending code in Python 1.5 Distutils is
at or around line 192 of bdist_rpm.py

In Python 2.1 it is also at line 192 of bdist_rpm.py

Thanks!



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:35

Message:
Logged In: YES 
user_id=11375

Fixed in revision 1.24 of bdist_rpm.py


----------------------------------------------------------------------

Comment By: Jon Nelson (jnelson)
Date: 2001-05-04 07:41

Message:
Logged In: YES 
user_id=8446

Here is a patch:

diff -u -r
Distutils-1.0.1.orig/distutils/command/bdist_rpm.py
Distutils-1.0.1/d
istutils/command/bdist_rpm.py
--- Distutils-1.0.1.orig/distutils/command/bdist_rpm.py Fri
May  4 09:25:32 2001
+++ Distutils-1.0.1/distutils/command/bdist_rpm.py      Fri
May  4 09:26:12 2001
@@ -189,7 +189,7 @@
         if type(self.doc_files) is ListType:
             for readme in ('README', 'README.txt'):
                 if os.path.exists(readme) and readme not in
self.doc_files:
-                    self.doc.append(readme)
+                    self.doc_files.append(readme)
 
         self.ensure_string('release', "1")
         self.ensure_string('serial')   # should it be an
int?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418369&group_id=5470


From noreply@sourceforge.net  Mon May 21 21:39:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 13:39:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips
Message-ID: <E151wSP-0001Sx-00@usw-sf-web3.sourceforge.net>

Bugs item #410541, was updated on 2001-03-22 08:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: bdist builds bogus .zips

Initial Comment:
According to Thomas Heller: "... the resulting zip-file
from
'bdist --formats=zip' is unusable because it contains
filenames relative to
the root directory)"

Such paths may be OK for Unix (cd / and unzip it,
perhaps?), 
but isn't much good for Windows, where Python might be
installed anywhere.  


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:39

Message:
Logged In: YES 
user_id=11375

I expect no one will install from a .zip file on Unix.

Options:

1) Make both the .tgz and .zip relative to sys.prefix or 
something.
2) Make only the .zip relative.
3) Document this as being broken and forget about it.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470


From noreply@sourceforge.net  Tue May 22 07:24:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 21 May 2001 23:24:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-425007 ] Python 2.1 installs shared libs with mode 0700
Message-ID: <E1525ak-0000Uf-00@usw-sf-web3.sourceforge.net>

Bugs item #425007, was updated on 2001-05-17 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: A.M. Kuchling (akuchling)
Summary: Python 2.1 installs shared libs with mode 0700

Initial Comment:
I have gone back and tried Python 1.6 and 2.0.  Both
work fine.  When I install Python 2.1, everything is
broken.  The problem is that when a module is a shared
library (.so), python refuses to load the module.  Example:

import os
import sys
import SocketServer

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/SocketServer.py", line 126, in ?
    import socket
  File "/usr/lib/python2.1/socket.py", line 41, in ?
    from _socket import *
ImportError: No module named _socket

Now, do a "locate _socket.so" and I get:
/usr/lib/python2.1/site-packages/_socket.so
/usr/lib/python2.1/lib-dynload/_socket.so


Clearly they are there, it's just that Python refuses
to load them.


I made Python 2.1 from source as fetched from the 2.1
tar ball.  It makes cleanly.  During the installation,
I see some items that I believe to be minor that popup,
but don't currectly expect that they are the problem. 
I have tried many times using different configure
options to get this to work, deleting the previous
installation each time.  I've even tried installing in
different locations.

As is, Python 2.1 is completely broken for me.  Surely
I'm not the only one having this problem, especially
since 1.5, 1.6, and 2.0 all work correctly.

Any help would be great.  BTW, doing a "print sys.path"
gives me: ['', '/usr/lib/python2.1',
'/usr/lib/python2.1/plat-linux2',
'/usr/lib/python2.1/lib-tk',
'/usr/lib/python2.1/lib-dynload',
'/usr/lib/python2.1/site-packages']

As you can see, lib-dynload is in the path, so I'm not
really sure what's going on.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-21 23:24

Message:
Logged In: YES 
user_id=149084

INSTALLATION:  Confirm. Built with umask 077, group and
others have no permissions in source tree. (Note that if I
su to install, the 077 follows! ok, install with umask of
022, normal for root.). Everything in installation looks ok
except for lib-dynload, which has 700 permissions on files.
No _socket.so in site-packages. 

REINSTALLATION:  I suspect there is more to this than
distutils...Redo the build with umask 022.  Then chmod the
whole previously installed tree to 700 and if you then
repeat the install on top of it you find that while the .py
files have been correctly copied by /usr/bin/install with
644, the .pyc and .pyo are still 700 though recompiled. 
This also happens in 1.5.2.  The lib-dynload files are 755.
This is with a umask of 022 for both the build user and
root. Finally, delete a few files from lib-dynload, chmod
the rest to 700, and make install again! The deleted files
are restored at 755, the rest stay at 700. In general,
messed up permissions are not fixed by a re-install.

It would seem desirable that re-installing should result in
exactly the same install tree as the initial install,
including permissions, except that any non-distribution
files (e.g. "site-packages") added by the user would be
unaffected.  If the user had modified some distribution .py
files they would be reverted by the re-install, which does
seem to be the case. A broken installation could be repaired
by re-installing.

Would that be a reasonable policy? Or is it too difficult to
fix up all the permissions? A compromise might be to delete
the .pyo .pyc before compiling, and explicitly chmod all the
lib-dynload files during install.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:15

Message:
Logged In: YES 
user_id=11375

Reclassifying as a Distutils bug.  

The install_lib subcommand simply copies the contents of 
the BUILD/ tree.  It needs to pointedly ignore the umask 
and set the proper permissions on the installed files.
  


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:32

Message:
Logged In: YES 
user_id=6380

Assigning this to Andrew -- clearly the setup.py script (or
distutils) needs to be fixed to fix this.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-21 12:24

Message:
Logged In: YES 
user_id=6380

I didn't mean to imply that you did something incorrectly. 
I just meant that there was some interaction between your
system and Python that didn't work out the way it was
supposed to be. Since Python installs correctly on most
systems, I was implying that there's something unusual in
your system that the Python install procedure doesn't
anticipate.

The mode 0700 for the shared libraries is a big hint at what
was wrong (and if you had done an ls -l of the file when
first reporting this we would have figured out the problem
much quicker). Is perhaps the umask of the user who built
(not installed) the files set to 077? In that case, the
cause is that the "make install" by root doesn't change the
file modes to something more reasonable (I've confirmed that
this indeed happens). I'll look into whether this can be
fixed. I'm changing the subject line of this bug report to
reflect more accurately that the problem is with the file
modes of shared libs.

I still believe that the _socket.so in site-packages could
not have been placed there by the normal Python install
procedure.


----------------------------------------------------------------------

Comment By: Greg Copeland (oracle)
Date: 2001-05-21 08:13

Message:
Logged In: YES 
user_id=40173

The problem is that the installation is partially broken. It
didn't install the shared libraries with proper permissions.
When Python installed the shared libs, it installed the libs
as root.root having 0700 permissions. When I tried to
execute it as a normal user, obviously, it fails to load the
shared lib. Python then, incorrectly reports that the shared
lib can not be found.  Of course, the correct solution is
for Python to accurately report the problem and to have the
installation always install the libraries with correct
ownership and permission.  I don't think I'm asking for too
much here.  Seems pretty reasonable to me.

Anyone stating that I did not install correctly is woefully
incorrect. Simply put, the installation is not 100%. As for
some of the libraries existing twice. Well, simply put, the
installation is not 100%.

At any rate, I think it's safe to close this bug but we
might want to add it to the faq-o-matic somewhere or some
such thing.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-20 10:35

Message:
Logged In: YES 
user_id=6380

Clearly it's something you have done to yourself. :-)  The
question is how to find out what.

Try "python -v" or even "python -vv" and see what it prints
when you try to import _socket. This should give you some
clues (it shows where it searches for modules during
import).

As kbk says, that other _socket.so is mysterious.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-19 17:16

Message:
Logged In: YES 
user_id=149084

Well, import SocketServer works ok for me with Python built
both from the 2.1 tar file and the 2.2a0 CVS tree. I'm
running Linux 2.2.5 (RH 6.2) on Pentium.

Did you make clean after changing the configure options?

It is not normal to have _socket.so in .../site-packages; it
should be only in .../lib-dynload.  Default installation has
only the README file in site-packages.

Your sys.path looks normal, except that Python default
installs at /usr/local/[bin/lib].  I tried a build targeted
at /usr/[bin/lib] and it was ok.

You could try make clobber, but it's almost as fast to start
over. Try a vanilla installation:
1. delete your install tree @ /usr/local/lib/python2.1
(and/or /usr/lib)
2. delete your source tree from wherever you unpacked the
tar file.
3. untar again, cd to source directory it created
4. without changing any files, and no configure options, run
./configure, then make, then make install

If that doesn't help, what Linux are you running, on what
box, and where did you get your 2.1 tar file?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425007&group_id=5470


From noreply@sourceforge.net  Tue May 22 09:32:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 01:32:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-417418 ] Python 2.1 compile error on HPUX
Message-ID: <E1527ai-00023d-00@usw-sf-web3.sourceforge.net>

Bugs item #417418, was updated on 2001-04-19 11:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470

Category: Build
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Python 2.1 compile error on HPUX

Initial Comment:
Compiling Python2.1 on HPUX11.0 gives the following 
errors:

cc: "Modules/termios.c", line 529: error 
1588: "VREPRINT" undefined.
cc: "Modules/termios.c", line 529: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 530: error 
1588: "VDISCARD" undefined.
cc: "Modules/termios.c", line 530: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 747: error 1588: "MDCD" 
undefined.
cc: "Modules/termios.c", line 747: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 750: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 753: error 1588: "MCTS" 
undefined.
cc: "Modules/termios.c", line 753: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 756: error 1588: "MDSR" 
undefined.
cc: "Modules/termios.c", line 756: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 759: error 1588: "MDTR" 
undefined.
cc: "Modules/termios.c", line 759: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 765: error 1588: "MRI" 
undefined.
cc: "Modules/termios.c", line 765: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 768: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 771: error 1588: "MRTS" 
undefined.
cc: "Modules/termios.c", line 771: error 1521: 
Incorrect initialization.


----------------------------------------------------------------------

>Comment By: Richard Townsend (rptownsend)
Date: 2001-05-22 01:32

Message:
Logged In: YES 
user_id=200117

I copied the following files from CVS 
Development/python/python/dist/src:
config.h.in configure configure.in Modules/termios.c
and tried to build. 

I got the following errors:

building 'termios' extension
cc -Ae -O +z -I. -I/home/richardt/python/Python-
2.1/./Include -I/usr/local/include -IInclude/ -
c /home/richardt/python/Python-2.1/Modules/termios.c -o 
build/temp.hp-ux-B.11.00-9000/770-2.1/termios.o
cc: "/home/richardt/python/Python-2.1/Modules/termios.c", 
line 540: error 1588: "VREPRINT" undefined.
cc: "/home/richardt/python/Python-2.1/Modules/termios.c", 
line 540: error 1521: Incorrect initialization.
cc: "/home/richardt/python/Python-2.1/Modules/termios.c", 
line 543: error 1588: "VDISCARD" undefined.
cc: "/home/richardt/python/Python-2.1/Modules/termios.c", 
line 543: error 1521: Incorrect initialization.
WARNING: building of extension "termios" failed: 
command 'cc' failed with exit status 1


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 09:37

Message:
Logged In: YES 
user_id=3066

I can't test on HP-UX, but have checked in the fix to both
the development and maintenance branches of Python.  If
someone using HP-UX could test Python from the CVS
repository (either branch) and report back, I'd appreciate it.

----------------------------------------------------------------------

Comment By: The Written Word (china) (tww-china)
Date: 2001-05-06 22:29

Message:
Logged In: YES 
user_id=119770

You can find a fix for this at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-417418.patch

You'll need to rerurn autoheader and autoconf before
testing.

----------------------------------------------------------------------

Comment By: Martin Jost (jost)
Date: 2001-05-04 01:55

Message:
Logged In: YES 
user_id=211439

The ones about M... (MCTS, MDTR, ...) are caused by the 
fact, that 
#include <sys/modem.h>
is needed for these on HPUX (10.20 at least) but not 
included.

But I found no fix for the V...-symbols


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-26 09:25

Message:
Logged In: NO 

The build also failes with HPUX B.10.20 A

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470


From noreply@sourceforge.net  Tue May 22 10:42:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 02:42:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-417418 ] Python 2.1 compile error on HPUX
Message-ID: <E1528gb-0005e7-00@usw-sf-web1.sourceforge.net>

Bugs item #417418, was updated on 2001-04-19 11:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470

Category: Build
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Python 2.1 compile error on HPUX

Initial Comment:
Compiling Python2.1 on HPUX11.0 gives the following 
errors:

cc: "Modules/termios.c", line 529: error 
1588: "VREPRINT" undefined.
cc: "Modules/termios.c", line 529: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 530: error 
1588: "VDISCARD" undefined.
cc: "Modules/termios.c", line 530: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 747: error 1588: "MDCD" 
undefined.
cc: "Modules/termios.c", line 747: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 750: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 753: error 1588: "MCTS" 
undefined.
cc: "Modules/termios.c", line 753: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 756: error 1588: "MDSR" 
undefined.
cc: "Modules/termios.c", line 756: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 759: error 1588: "MDTR" 
undefined.
cc: "Modules/termios.c", line 759: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 765: error 1588: "MRI" 
undefined.
cc: "Modules/termios.c", line 765: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 768: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 771: error 1588: "MRTS" 
undefined.
cc: "Modules/termios.c", line 771: error 1521: 
Incorrect initialization.


----------------------------------------------------------------------

>Comment By: Richard Townsend (rptownsend)
Date: 2001-05-22 02:42

Message:
Logged In: YES 
user_id=200117

I notice that lines 539 & 542 in CVS repository termios.c 
use #ifndef and not #ifdef (which was used in the patch 
provided by ftp.thewrittenword.com).
When I changed these lines to #ifdef the module does 
compile and I can import termios ok.


----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2001-05-22 01:32

Message:
Logged In: YES 
user_id=200117

I copied the following files from CVS 
Development/python/python/dist/src:
config.h.in configure configure.in Modules/termios.c
and tried to build. 

I got the following errors:

building 'termios' extension
cc -Ae -O +z -I. -I/home/richardt/python/Python-
2.1/./Include -I/usr/local/include -IInclude/ -
c /home/richardt/python/Python-2.1/Modules/termios.c -o 
build/temp.hp-ux-B.11.00-9000/770-2.1/termios.o
cc: "/home/richardt/python/Python-2.1/Modules/termios.c", 
line 540: error 1588: "VREPRINT" undefined.
cc: "/home/richardt/python/Python-2.1/Modules/termios.c", 
line 540: error 1521: Incorrect initialization.
cc: "/home/richardt/python/Python-2.1/Modules/termios.c", 
line 543: error 1588: "VDISCARD" undefined.
cc: "/home/richardt/python/Python-2.1/Modules/termios.c", 
line 543: error 1521: Incorrect initialization.
WARNING: building of extension "termios" failed: 
command 'cc' failed with exit status 1


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 09:37

Message:
Logged In: YES 
user_id=3066

I can't test on HP-UX, but have checked in the fix to both
the development and maintenance branches of Python.  If
someone using HP-UX could test Python from the CVS
repository (either branch) and report back, I'd appreciate it.

----------------------------------------------------------------------

Comment By: The Written Word (china) (tww-china)
Date: 2001-05-06 22:29

Message:
Logged In: YES 
user_id=119770

You can find a fix for this at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-417418.patch

You'll need to rerurn autoheader and autoconf before
testing.

----------------------------------------------------------------------

Comment By: Martin Jost (jost)
Date: 2001-05-04 01:55

Message:
Logged In: YES 
user_id=211439

The ones about M... (MCTS, MDTR, ...) are caused by the 
fact, that 
#include <sys/modem.h>
is needed for these on HPUX (10.20 at least) but not 
included.

But I found no fix for the V...-symbols


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-26 09:25

Message:
Logged In: NO 

The build also failes with HPUX B.10.20 A

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470


From noreply@sourceforge.net  Tue May 22 11:12:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 03:12:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Unicode Build Prob.
Message-ID: <E15299D-0003WM-00@usw-sf-web2.sourceforge.net>

Bugs item #420416, was updated on 2001-05-01 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Schinckel (schinckel)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Python for BeOS/PPC Unicode Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

----------------------------------------------------------------------

>Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 03:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 02:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 04:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470


From noreply@sourceforge.net  Tue May 22 16:45:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 08:45:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-417418 ] Python 2.1 compile error on HPUX
Message-ID: <E152ELW-0003VB-00@usw-sf-web1.sourceforge.net>

Bugs item #417418, was updated on 2001-04-19 11:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470

Category: Build
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Python 2.1 compile error on HPUX

Initial Comment:
Compiling Python2.1 on HPUX11.0 gives the following 
errors:

cc: "Modules/termios.c", line 529: error 
1588: "VREPRINT" undefined.
cc: "Modules/termios.c", line 529: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 530: error 
1588: "VDISCARD" undefined.
cc: "Modules/termios.c", line 530: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 747: error 1588: "MDCD" 
undefined.
cc: "Modules/termios.c", line 747: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 750: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 753: error 1588: "MCTS" 
undefined.
cc: "Modules/termios.c", line 753: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 756: error 1588: "MDSR" 
undefined.
cc: "Modules/termios.c", line 756: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 759: error 1588: "MDTR" 
undefined.
cc: "Modules/termios.c", line 759: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 765: error 1588: "MRI" 
undefined.
cc: "Modules/termios.c", line 765: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 768: error 1521: 
Incorrect initialization.
cc: "Modules/termios.c", line 771: error 1588: "MRTS" 
undefined.
cc: "Modules/termios.c", line 771: error 1521: 
Incorrect initialization.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-22 08:45

Message:
Logged In: YES 
user_id=3066

--sigh--....  OK, I've fixed this in Modules/termios.c revision 2.29 -- sorry!

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2001-05-22 02:42

Message:
Logged In: YES 
user_id=200117

I notice that lines 539 & 542 in CVS repository termios.c 
use #ifndef and not #ifdef (which was used in the patch 
provided by ftp.thewrittenword.com).
When I changed these lines to #ifdef the module does 
compile and I can import termios ok.


----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2001-05-22 01:32

Message:
Logged In: YES 
user_id=200117

I copied the following files from CVS 
Development/python/python/dist/src:
config.h.in configure configure.in Modules/termios.c
and tried to build. 

I got the following errors:

building 'termios' extension
cc -Ae -O +z -I. -I/home/richardt/python/Python-
2.1/./Include -I/usr/local/include -IInclude/ -
c /home/richardt/python/Python-2.1/Modules/termios.c -o 
build/temp.hp-ux-B.11.00-9000/770-2.1/termios.o
cc: "/home/richardt/python/Python-2.1/Modules/termios.c", 
line 540: error 1588: "VREPRINT" undefined.
cc: "/home/richardt/python/Python-2.1/Modules/termios.c", 
line 540: error 1521: Incorrect initialization.
cc: "/home/richardt/python/Python-2.1/Modules/termios.c", 
line 543: error 1588: "VDISCARD" undefined.
cc: "/home/richardt/python/Python-2.1/Modules/termios.c", 
line 543: error 1521: Incorrect initialization.
WARNING: building of extension "termios" failed: 
command 'cc' failed with exit status 1


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 09:37

Message:
Logged In: YES 
user_id=3066

I can't test on HP-UX, but have checked in the fix to both
the development and maintenance branches of Python.  If
someone using HP-UX could test Python from the CVS
repository (either branch) and report back, I'd appreciate it.

----------------------------------------------------------------------

Comment By: The Written Word (china) (tww-china)
Date: 2001-05-06 22:29

Message:
Logged In: YES 
user_id=119770

You can find a fix for this at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-417418.patch

You'll need to rerurn autoheader and autoconf before
testing.

----------------------------------------------------------------------

Comment By: Martin Jost (jost)
Date: 2001-05-04 01:55

Message:
Logged In: YES 
user_id=211439

The ones about M... (MCTS, MDTR, ...) are caused by the 
fact, that 
#include <sys/modem.h>
is needed for these on HPUX (10.20 at least) but not 
included.

But I found no fix for the V...-symbols


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-26 09:25

Message:
Logged In: NO 

The build also failes with HPUX B.10.20 A

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417418&group_id=5470


From noreply@sourceforge.net  Tue May 22 17:58:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 09:58:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-426345 ] Problem with addition
Message-ID: <E152FUK-0008IM-00@usw-sf-web2.sourceforge.net>

Bugs item #426345, was updated on 2001-05-22 09:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426345&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with addition

Initial Comment:
There seems to be a problem with addition in the 
python interactive mode.  This is what I did:

"""

[administrator@RGELPC265 delacruz]$ python
Python 2.1 (#1, Apr 17 2001, 09:45:01)
[GCC 2.95.3-2 (cygwin special)] on cygwin_nt-4.01
Type "copyright", "credits" or "license" for more 
information.
>>> 3.76 + 4.72
8.4800000000000004

"""

Here are my specs:

Python Release:  Python 2.1 (#1, Apr 17 2001, 09:45:01)
Platform:  Windows 2000
Shell:  cygwin


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426345&group_id=5470


From noreply@sourceforge.net  Tue May 22 19:29:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 11:29:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-420304 ] getattr function w/ default
Message-ID: <E152GuB-0006RZ-00@usw-sf-web1.sourceforge.net>

Bugs item #420304, was updated on 2001-04-30 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Greg Chapman (glchapman)
Assigned to: Jeremy Hylton (jhylton)
Summary: getattr function w/ default

Initial Comment:
In Python 2.1, when calling the builtin getattr 
function and supplying the (optional) default 
argument, this default is returned on any exception 
raised during PyObject_GetAttr, even if the exception 
is not an AttributeError.  I did not expect this 
behavior after reading the getattr documentation.  Is 
this the  intended behavior?  (If so, I think the 
documentation should be made clearer on this point.)

Example (providing a non-string as the attribute name):

>>> class Test:
... 	pass
... 
>>> t = Test()
>>> getattr(t, 1, "hello")
'hello'
>>> 


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-05-22 11:29

Message:
Logged In: YES 
user_id=89016

But unicode attr arguments should be allowed, because 
someday in the far future Python might be unicode based.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-07 21:26

Message:
Logged In: YES 
user_id=31392

This looks like a bug to me, too.  I think a non-string attr
argument
to getattr()  should raise TypeError.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-05-04 04:11

Message:
Logged In: YES 
user_id=6656

But consider this:

>>> getattr({},1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: attribute name must be string
>>> getattr({},1,"e")
'e'

or

>>> getattr(None,u"\343","e")
'e'
>>> getattr(None,u"\343")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII encoding error: ordinal not in range(128)

Here's a possible patch:

Index: bltinmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v
retrieving revision 2.200
diff -c -r2.200 bltinmodule.c
*** bltinmodule.c       2001/05/02 07:39:38     2.200
--- bltinmodule.c       2001/05/04 11:09:35
***************
*** 845,850 ****
--- 845,854 ----
  The globals and locals are dictionaries, defaulting to the
current\n\
  globals and locals.  If only globals is given, locals
defaults to it.";
  
+ /* Internal API needed by builtin_getattr(): */
+ extern 
+ PyObject *_PyUnicode_AsDefaultEncodedString(PyObject *unicode,
+                                 const char *errors);
  
  static PyObject *
  builtin_getattr(PyObject *self, PyObject *args)
***************
*** 854,859 ****
--- 858,874 ----
  
        if (!PyArg_ParseTuple(args, "OO|O:getattr", &v,
&name, &dflt))
                return NULL;
+       if (PyUnicode_Check(name)) {
+               name =
_PyUnicode_AsDefaultEncodedString(name, NULL);
+               if (name == NULL)
+                       return NULL;
+       } 
+       else if (!PyString_Check(name)) {
+               PyErr_Format(PyExc_TypeError,
+            "getattr: attribute name must be string, not
\%.500s\",
+                            name->ob_type->tp_name);
+               return NULL;
+       }
        result = PyObject_GetAttr(v, name);
        if (result == NULL && dflt != NULL) {
                PyErr_Clear();

... though by the time you've done all that, there's not
much point in calling PyObject_GetAttr at all...

OTOH, this changes behaviour, so maybe one should just
clarify this in the docs.

----------------------------------------------------------------------

Comment By: Chris Cogdon (chriscog)
Date: 2001-05-03 17:55

Message:
Logged In: YES 
user_id=67116

Looks like an attribute error to me. consider this:

>>> getattr (t,fred,"thingy")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: There is no variable named 'fred'

Ie, in your own example, it couldn't find an attribute '1' 
in the class, even if its an integer attribute (which is 
only obtainable using getattr/setattr). That's exactly what 
AttributeError is

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470


From noreply@sourceforge.net  Tue May 22 19:42:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 11:42:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-420304 ] getattr function w/ default
Message-ID: <E152H72-00016Z-00@usw-sf-web2.sourceforge.net>

Bugs item #420304, was updated on 2001-04-30 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Greg Chapman (glchapman)
Assigned to: Jeremy Hylton (jhylton)
Summary: getattr function w/ default

Initial Comment:
In Python 2.1, when calling the builtin getattr 
function and supplying the (optional) default 
argument, this default is returned on any exception 
raised during PyObject_GetAttr, even if the exception 
is not an AttributeError.  I did not expect this 
behavior after reading the getattr documentation.  Is 
this the  intended behavior?  (If so, I think the 
documentation should be made clearer on this point.)

Example (providing a non-string as the attribute name):

>>> class Test:
... 	pass
... 
>>> t = Test()
>>> getattr(t, 1, "hello")
'hello'
>>> 


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-05-22 11:42

Message:
Logged In: YES 
user_id=6656

Well, the patch I posted below allows unicode (though
admittedly only for strings that can be encoded using the
default encoding).

Have you read the code to object.c:PyObject_GetAttr?  All my
code does is hoist some of the error checking out of there
into getattr to better decide whether to return the provided
default value.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-05-22 11:29

Message:
Logged In: YES 
user_id=89016

But unicode attr arguments should be allowed, because 
someday in the far future Python might be unicode based.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-07 21:26

Message:
Logged In: YES 
user_id=31392

This looks like a bug to me, too.  I think a non-string attr
argument
to getattr()  should raise TypeError.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-05-04 04:11

Message:
Logged In: YES 
user_id=6656

But consider this:

>>> getattr({},1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: attribute name must be string
>>> getattr({},1,"e")
'e'

or

>>> getattr(None,u"\343","e")
'e'
>>> getattr(None,u"\343")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII encoding error: ordinal not in range(128)

Here's a possible patch:

Index: bltinmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v
retrieving revision 2.200
diff -c -r2.200 bltinmodule.c
*** bltinmodule.c       2001/05/02 07:39:38     2.200
--- bltinmodule.c       2001/05/04 11:09:35
***************
*** 845,850 ****
--- 845,854 ----
  The globals and locals are dictionaries, defaulting to the
current\n\
  globals and locals.  If only globals is given, locals
defaults to it.";
  
+ /* Internal API needed by builtin_getattr(): */
+ extern 
+ PyObject *_PyUnicode_AsDefaultEncodedString(PyObject *unicode,
+                                 const char *errors);
  
  static PyObject *
  builtin_getattr(PyObject *self, PyObject *args)
***************
*** 854,859 ****
--- 858,874 ----
  
        if (!PyArg_ParseTuple(args, "OO|O:getattr", &v,
&name, &dflt))
                return NULL;
+       if (PyUnicode_Check(name)) {
+               name =
_PyUnicode_AsDefaultEncodedString(name, NULL);
+               if (name == NULL)
+                       return NULL;
+       } 
+       else if (!PyString_Check(name)) {
+               PyErr_Format(PyExc_TypeError,
+            "getattr: attribute name must be string, not
\%.500s\",
+                            name->ob_type->tp_name);
+               return NULL;
+       }
        result = PyObject_GetAttr(v, name);
        if (result == NULL && dflt != NULL) {
                PyErr_Clear();

... though by the time you've done all that, there's not
much point in calling PyObject_GetAttr at all...

OTOH, this changes behaviour, so maybe one should just
clarify this in the docs.

----------------------------------------------------------------------

Comment By: Chris Cogdon (chriscog)
Date: 2001-05-03 17:55

Message:
Logged In: YES 
user_id=67116

Looks like an attribute error to me. consider this:

>>> getattr (t,fred,"thingy")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: There is no variable named 'fred'

Ie, in your own example, it couldn't find an attribute '1' 
in the class, even if its an integer attribute (which is 
only obtainable using getattr/setattr). That's exactly what 
AttributeError is

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470


From noreply@sourceforge.net  Tue May 22 20:42:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 12:42:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-423157 ] Python 2.1 Idle does not run on Win98
Message-ID: <E152I3U-0007jg-00@usw-sf-web1.sourceforge.net>

Bugs item #423157, was updated on 2001-05-10 13:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423157&group_id=5470

Category: IDLE
Group: Platform-specific
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: Python 2.1 Idle does not run on Win98

Initial Comment:
After downloading and running Python2-1.exe to install 
Python 2.1 on Windows 98 we are finding that the Idle 
application does not appear to run at all.

Clicking on Idle causes the hourglass to come up 
momentarily and then -- nothing.

Any ideas as to what is wrong?

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-22 12:42

Message:
Logged In: YES 
user_id=31435

Closed as "Works For Me":  it's heading on 2 weeks and 
there's been no followup from the anonymous submitter, 
neither any other reports of this behavior.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-11 13:00

Message:
Logged In: YES 
user_id=31435

I run IDLE under 2.1 on Win98 every day.  No problem.

>From where did you obtain Python?  "Python2-1.exe" isn't a 
file name I recognize, so I don't know, for example, 
whether you got 2.1 from python.org, or ActiveState, or 
etc.  You certainly didn't get a file named Python2-1.exe 
from python.org.  The distributions differ in some 
respects, so we can't make any progress here without more 
info from you.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423157&group_id=5470


From noreply@sourceforge.net  Tue May 22 20:43:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 12:43:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-214846 ] python20_d.dll missing
Message-ID: <E152I3v-0007kJ-00@usw-sf-web1.sourceforge.net>

Bugs item #214846, was updated on 2000-09-19 19:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=214846&group_id=5470

Category: Windows
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Aria Kraft (psykotron)
Assigned to: Guido van Rossum (gvanrossum)
Summary: python20_d.dll missing

Initial Comment:
The file python20_d.dll is missing from the
win32-binary distribution.
side note: in python 1.5 this could be worked around
by linking to python15.lib manually. In 1.6 & 2.0 this
work around does not work.
(this is of course when python is embedded into a win32
application)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-22 12:43

Message:
Logged In: NO 

I'm getting the dreaded err msg >> LINK : fatal error 
LNK1104: cannot open file "python21_d.lib"

Is there a fix for embedding into win32 apps?  
Kevin

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-20 18:06

Message:
Hmm.  Guido, turns out we're already shipping the debug DLLs for the extension modules!

C:\Python20\DLLs>dir *_d.pyd

 Volume in drive C has no label
 Volume Serial Number is 3459-5C23
 Directory of C:\Python20\DLLs

PARSER_D PYD        65,597  09-07-00  2:42a parser_d.pyd
_SOCKE~1 PYD        53,310  09-07-00  2:41a _socket_d.pyd
_SRE_D   PYD        45,115  09-07-00  2:41a _sre_d.pyd
MMAP_D   PYD        36,923  09-07-00  2:42a mmap_d.pyd
SELECT_D PYD        32,829  09-07-00  2:42a select_d.pyd
UCNHAS~1 PYD       548,926  09-07-00  2:42a ucnhash_d.pyd
UNICOD~2 PYD       733,250  09-07-00  2:42a unicodedata_d.pyd
_WINRE~1 PYD        57,406  09-07-00  2:43a _winreg_d.pyd
WINSOU~1 PYD        28,735  09-07-00  2:43a winsound_d.pyd
_TKINT~1 PYD        53,311  09-07-00  2:42a _tkinter_d.pyd
PYEXPA~1 PYD        45,118  09-07-00  2:42a pyexpat_d.pyd
BSDDB_D  PYD       106,556  09-07-00  2:42a bsddb_d.pyd
ZLIB_D   PYD        86,075  09-07-00  2:43a zlib_d.pyd
        13 file(s)      1,893,151 bytes
         0 dir(s)        2,551.06 MB free

C:\Python20\DLLs>

Closing in on 2Mb of fat I can cut out of the installer!

PSKOtron, no, thank you, but I'm not going to build a new installer just so "a couple people" have an easier time.  That isn't cruelty <wink>, it's that thousands of people are waiting for more important things and my time (like yours) is limited.  If someone wants to contribute such an installer, cool.  Else the best I can manage is a no-time approach, such as putting all the _d files into a .zip file at release points and uploading that to an FTP site.

----------------------------------------------------------------------

Comment By: Aria Kraft (psykotron)
Date: 2000-09-20 12:23

Message:
I would appreciate it if you can add it into a seperate installer for experts. At the moment I have to compile
all of python, and redistribute all the debug and non-debug lib's and dll's to a couple people responsible for debugging my program. Basicly I used to use the windows installer for the debuggers, now I have to make my own, and
install it manually to each programmer's system.
I believe linux distributions solved this problem by releasing: somelib-1.0 && somelib-1.0-dev
:)
Thanks for all your hard work in python... its helped *a lot* in my project.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-20 06:21

Message:
Sorry, I won't fix this. The debug DLL is huge, and you'd need more than just python20_d.dll -- you'd need the _d.pyd version of all the extension modules. This would just be a waste of installer size.

If you have a need for the debug DLLs, you should download the sources and rebuild with debug mode from source. After all you must be debugging something so you must already be using VC++ so rebuilding won't be a problem; see PCbuild/readme.txt for elaborate instructions.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-19 23:41

Message:
Guido, I assigned this to you just to get your attention:  what do you think?  (MarkH, if you're listening, you too!)

C:\Code\python\dist\src\PCbuild>dir py*.dll

PYTHON20 DLL       692,285  09-19-00 10:14p python20.dll
PYTHON~1 DLL     1,138,751  09-19-00 10:14p python20_d.dll
         2 file(s)      1,831,036 bytes
         0 dir(s)        2,554.24 MB free

C:\Code\python\dist\src\PCbuild>

The debug DLL is a megabyte now, and I personally don't want to bloat the installer with it given that not one user in 1,000 will have any use for it.  Perhaps we could make it available as a separate download for experts?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=214846&group_id=5470


From noreply@sourceforge.net  Tue May 22 20:43:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 12:43:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-426345 ] Problem with addition
Message-ID: <E152I48-0007kU-00@usw-sf-web1.sourceforge.net>

Bugs item #426345, was updated on 2001-05-22 09:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426345&group_id=5470

Category: None
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with addition

Initial Comment:
There seems to be a problem with addition in the 
python interactive mode.  This is what I did:

"""

[administrator@RGELPC265 delacruz]$ python
Python 2.1 (#1, Apr 17 2001, 09:45:01)
[GCC 2.95.3-2 (cygwin special)] on cygwin_nt-4.01
Type "copyright", "credits" or "license" for more 
information.
>>> 3.76 + 4.72
8.4800000000000004

"""

Here are my specs:

Python Release:  Python 2.1 (#1, Apr 17 2001, 09:45:01)
Platform:  Windows 2000
Shell:  cygwin


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-22 12:43

Message:
Logged In: YES 
user_id=31435

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for a detailed example:

http://www.python.org/cgi-bin/moinmoin/RepresentationError


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426345&group_id=5470


From noreply@sourceforge.net  Tue May 22 20:44:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 12:44:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-425261 ] re propagates opaque exceptions
Message-ID: <E152I4t-0007lA-00@usw-sf-web1.sourceforge.net>

Bugs item #425261, was updated on 2001-05-18 10:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425261&group_id=5470

Category: Regular Expressions
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fredrik Lundh (effbot)
Summary: re propagates opaque exceptions

Initial Comment:
If you call re.compile() with an erroneous expression,
the
underlying extension module (pcre, sre, ...?) raises an
exception which is propagated through re to the caller.

In order to catch the exception, it seems that you need
to
use an unqualified except clause, unless you import the
extension module, which is presumably supposed to be
opaque (particularly if its identity is variable!)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-22 12:44

Message:
Logged In: YES 
user_id=31435

/F forgot to close this -- closing it.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 13:54

Message:
Logged In: YES 
user_id=31435

Sounds good to me!  Did you leave this open because you 
thought you were bluffing <wink>?


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-18 13:43

Message:
Logged In: NO 

not a bug.

The "compile" method throws an "error" exception from
the *same* module, no matter what regular expression
module you're using.  This is how it's documented, and
this is how it works.

Or in other words, the following works, whether you've
used "import re", "import sre as re", or "import pre as
re":

   try:
      p = re.compile(...)
   except re.error:
      print "gotcha"

</F>

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 13:12

Message:
Logged In: YES 
user_id=31435

Assigned to /F.  Would probably be better if, e.g., 
sre_constants.error were a subclass of, say, SyntaxError?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425261&group_id=5470


From noreply@sourceforge.net  Tue May 22 20:49:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 12:49:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-214846 ] python20_d.dll missing
Message-ID: <E152IAC-0007qD-00@usw-sf-web1.sourceforge.net>

Bugs item #214846, was updated on 2000-09-19 19:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=214846&group_id=5470

Category: Windows
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Aria Kraft (psykotron)
Assigned to: Guido van Rossum (gvanrossum)
Summary: python20_d.dll missing

Initial Comment:
The file python20_d.dll is missing from the
win32-binary distribution.
side note: in python 1.5 this could be worked around
by linking to python15.lib manually. In 1.6 & 2.0 this
work around does not work.
(this is of course when python is embedded into a win32
application)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-05-22 12:49

Message:
Logged In: YES 
user_id=6380

Kevin,

Try Python-2.1-Debug.zip -- see http://www.python.org/2.1/

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-22 12:43

Message:
Logged In: NO 

I'm getting the dreaded err msg >> LINK : fatal error 
LNK1104: cannot open file "python21_d.lib"

Is there a fix for embedding into win32 apps?  
Kevin

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-20 18:06

Message:
Hmm.  Guido, turns out we're already shipping the debug DLLs for the extension modules!

C:\Python20\DLLs>dir *_d.pyd

 Volume in drive C has no label
 Volume Serial Number is 3459-5C23
 Directory of C:\Python20\DLLs

PARSER_D PYD        65,597  09-07-00  2:42a parser_d.pyd
_SOCKE~1 PYD        53,310  09-07-00  2:41a _socket_d.pyd
_SRE_D   PYD        45,115  09-07-00  2:41a _sre_d.pyd
MMAP_D   PYD        36,923  09-07-00  2:42a mmap_d.pyd
SELECT_D PYD        32,829  09-07-00  2:42a select_d.pyd
UCNHAS~1 PYD       548,926  09-07-00  2:42a ucnhash_d.pyd
UNICOD~2 PYD       733,250  09-07-00  2:42a unicodedata_d.pyd
_WINRE~1 PYD        57,406  09-07-00  2:43a _winreg_d.pyd
WINSOU~1 PYD        28,735  09-07-00  2:43a winsound_d.pyd
_TKINT~1 PYD        53,311  09-07-00  2:42a _tkinter_d.pyd
PYEXPA~1 PYD        45,118  09-07-00  2:42a pyexpat_d.pyd
BSDDB_D  PYD       106,556  09-07-00  2:42a bsddb_d.pyd
ZLIB_D   PYD        86,075  09-07-00  2:43a zlib_d.pyd
        13 file(s)      1,893,151 bytes
         0 dir(s)        2,551.06 MB free

C:\Python20\DLLs>

Closing in on 2Mb of fat I can cut out of the installer!

PSKOtron, no, thank you, but I'm not going to build a new installer just so "a couple people" have an easier time.  That isn't cruelty <wink>, it's that thousands of people are waiting for more important things and my time (like yours) is limited.  If someone wants to contribute such an installer, cool.  Else the best I can manage is a no-time approach, such as putting all the _d files into a .zip file at release points and uploading that to an FTP site.

----------------------------------------------------------------------

Comment By: Aria Kraft (psykotron)
Date: 2000-09-20 12:23

Message:
I would appreciate it if you can add it into a seperate installer for experts. At the moment I have to compile
all of python, and redistribute all the debug and non-debug lib's and dll's to a couple people responsible for debugging my program. Basicly I used to use the windows installer for the debuggers, now I have to make my own, and
install it manually to each programmer's system.
I believe linux distributions solved this problem by releasing: somelib-1.0 && somelib-1.0-dev
:)
Thanks for all your hard work in python... its helped *a lot* in my project.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-20 06:21

Message:
Sorry, I won't fix this. The debug DLL is huge, and you'd need more than just python20_d.dll -- you'd need the _d.pyd version of all the extension modules. This would just be a waste of installer size.

If you have a need for the debug DLLs, you should download the sources and rebuild with debug mode from source. After all you must be debugging something so you must already be using VC++ so rebuilding won't be a problem; see PCbuild/readme.txt for elaborate instructions.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-19 23:41

Message:
Guido, I assigned this to you just to get your attention:  what do you think?  (MarkH, if you're listening, you too!)

C:\Code\python\dist\src\PCbuild>dir py*.dll

PYTHON20 DLL       692,285  09-19-00 10:14p python20.dll
PYTHON~1 DLL     1,138,751  09-19-00 10:14p python20_d.dll
         2 file(s)      1,831,036 bytes
         0 dir(s)        2,554.24 MB free

C:\Code\python\dist\src\PCbuild>

The debug DLL is a megabyte now, and I personally don't want to bloat the installer with it given that not one user in 1,000 will have any use for it.  Perhaps we could make it available as a separate download for experts?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=214846&group_id=5470


From noreply@sourceforge.net  Tue May 22 21:13:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 13:13:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-420304 ] getattr function w/ default
Message-ID: <E152IWs-0008Gh-00@usw-sf-web1.sourceforge.net>

Bugs item #420304, was updated on 2001-04-30 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Greg Chapman (glchapman)
Assigned to: Jeremy Hylton (jhylton)
Summary: getattr function w/ default

Initial Comment:
In Python 2.1, when calling the builtin getattr 
function and supplying the (optional) default 
argument, this default is returned on any exception 
raised during PyObject_GetAttr, even if the exception 
is not an AttributeError.  I did not expect this 
behavior after reading the getattr documentation.  Is 
this the  intended behavior?  (If so, I think the 
documentation should be made clearer on this point.)

Example (providing a non-string as the attribute name):

>>> class Test:
... 	pass
... 
>>> t = Test()
>>> getattr(t, 1, "hello")
'hello'
>>> 


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-22 13:13

Message:
Logged In: YES 
user_id=38388

I guess the right thing to do here, would be to only mask
AttributeErrors in the getattr() builtin.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-05-22 11:42

Message:
Logged In: YES 
user_id=6656

Well, the patch I posted below allows unicode (though
admittedly only for strings that can be encoded using the
default encoding).

Have you read the code to object.c:PyObject_GetAttr?  All my
code does is hoist some of the error checking out of there
into getattr to better decide whether to return the provided
default value.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-05-22 11:29

Message:
Logged In: YES 
user_id=89016

But unicode attr arguments should be allowed, because 
someday in the far future Python might be unicode based.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-07 21:26

Message:
Logged In: YES 
user_id=31392

This looks like a bug to me, too.  I think a non-string attr
argument
to getattr()  should raise TypeError.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-05-04 04:11

Message:
Logged In: YES 
user_id=6656

But consider this:

>>> getattr({},1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: attribute name must be string
>>> getattr({},1,"e")
'e'

or

>>> getattr(None,u"\343","e")
'e'
>>> getattr(None,u"\343")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII encoding error: ordinal not in range(128)

Here's a possible patch:

Index: bltinmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v
retrieving revision 2.200
diff -c -r2.200 bltinmodule.c
*** bltinmodule.c       2001/05/02 07:39:38     2.200
--- bltinmodule.c       2001/05/04 11:09:35
***************
*** 845,850 ****
--- 845,854 ----
  The globals and locals are dictionaries, defaulting to the
current\n\
  globals and locals.  If only globals is given, locals
defaults to it.";
  
+ /* Internal API needed by builtin_getattr(): */
+ extern 
+ PyObject *_PyUnicode_AsDefaultEncodedString(PyObject *unicode,
+                                 const char *errors);
  
  static PyObject *
  builtin_getattr(PyObject *self, PyObject *args)
***************
*** 854,859 ****
--- 858,874 ----
  
        if (!PyArg_ParseTuple(args, "OO|O:getattr", &v,
&name, &dflt))
                return NULL;
+       if (PyUnicode_Check(name)) {
+               name =
_PyUnicode_AsDefaultEncodedString(name, NULL);
+               if (name == NULL)
+                       return NULL;
+       } 
+       else if (!PyString_Check(name)) {
+               PyErr_Format(PyExc_TypeError,
+            "getattr: attribute name must be string, not
\%.500s\",
+                            name->ob_type->tp_name);
+               return NULL;
+       }
        result = PyObject_GetAttr(v, name);
        if (result == NULL && dflt != NULL) {
                PyErr_Clear();

... though by the time you've done all that, there's not
much point in calling PyObject_GetAttr at all...

OTOH, this changes behaviour, so maybe one should just
clarify this in the docs.

----------------------------------------------------------------------

Comment By: Chris Cogdon (chriscog)
Date: 2001-05-03 17:55

Message:
Logged In: YES 
user_id=67116

Looks like an attribute error to me. consider this:

>>> getattr (t,fred,"thingy")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: There is no variable named 'fred'

Ie, in your own example, it couldn't find an attribute '1' 
in the class, even if its an integer attribute (which is 
only obtainable using getattr/setattr). That's exactly what 
AttributeError is

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470


From noreply@sourceforge.net  Tue May 22 23:19:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 15:19:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-426473 ] Need docs for writing PyUnit-based tests
Message-ID: <E152KV0-00059S-00@usw-sf-web3.sourceforge.net>

Bugs item #426473, was updated on 2001-05-22 15:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426473&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Need docs for writing PyUnit-based tests

Initial Comment:
The Lib/test/README file does not describe how to use
PyUnit for Python regression tests, and conventions
used in doing so.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426473&group_id=5470


From noreply@sourceforge.net  Wed May 23 01:52:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 17:52:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-426504 ] urllib fail with MS proxy
Message-ID: <E152Msa-0005FA-00@usw-sf-web2.sourceforge.net>

Bugs item #426504, was updated on 2001-05-22 17:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426504&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib fail with MS proxy

Initial Comment:
urllib can not perform due to the present of MS proxy. 
After remove the auto-detect portation, it works.

I have to force remove the getproxies code to make it 
work:

class URLopener:
    """Class to open URLs.
    This is a class rather than just a subroutine 
because we may need
    more than one set of global protocol-specific 
options.
    Note -- this is a base class for those who don't 
want the
    automatic handling of errors type 302 (relocated) 
and 401
    (authorization needed)."""

    __tempfiles = None

    version = "Python-urllib/%s" % __version__

    # Constructor
    def __init__(self, proxies=None, **x509):
        if proxies is None:
            proxies = {}
            # proxies = getproxies()
 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426504&group_id=5470


From noreply@sourceforge.net  Wed May 23 02:18:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 18:18:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-420304 ] getattr function w/ default
Message-ID: <E152NIh-0007Kn-00@usw-sf-web3.sourceforge.net>

Bugs item #420304, was updated on 2001-04-30 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Greg Chapman (glchapman)
Assigned to: Jeremy Hylton (jhylton)
Summary: getattr function w/ default

Initial Comment:
In Python 2.1, when calling the builtin getattr 
function and supplying the (optional) default 
argument, this default is returned on any exception 
raised during PyObject_GetAttr, even if the exception 
is not an AttributeError.  I did not expect this 
behavior after reading the getattr documentation.  Is 
this the  intended behavior?  (If so, I think the 
documentation should be made clearer on this point.)

Example (providing a non-string as the attribute name):

>>> class Test:
... 	pass
... 
>>> t = Test()
>>> getattr(t, 1, "hello")
'hello'
>>> 


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-22 18:18

Message:
Logged In: YES 
user_id=31435

Oh no:  getattr hooks can raise any exception whatsoever, 
and existing code relies on getattr() treating any 
exception whatsoever as meaning "no attribute of that 
name".  For example, IndexError and KeyError are often 
raised naturally by getattr hooks that fail to resolve a 
name via tree or dict structures.

The specific complaint here is a different story:  the docs 
say the attribute argument must be a string (Unicode, 
whatever -- "a string" <wink>), and I agree that calling 
getattr() with something other than a string argument 
should raise a TypeError instead of pretending it's a 
*possible* attribute name and that there simply isn't any 
attribute with that name (it's not a name at all, so the 
call doesn't make sense).

Jeremy, I see this is assigned to you now.  There are 
enough conflicting opinions here (at least Michael's and 
mine seem to coincide) that perhaps it's time to dump it on 
Guido for Pronouncement.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-22 13:13

Message:
Logged In: YES 
user_id=38388

I guess the right thing to do here, would be to only mask
AttributeErrors in the getattr() builtin.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-05-22 11:42

Message:
Logged In: YES 
user_id=6656

Well, the patch I posted below allows unicode (though
admittedly only for strings that can be encoded using the
default encoding).

Have you read the code to object.c:PyObject_GetAttr?  All my
code does is hoist some of the error checking out of there
into getattr to better decide whether to return the provided
default value.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-05-22 11:29

Message:
Logged In: YES 
user_id=89016

But unicode attr arguments should be allowed, because 
someday in the far future Python might be unicode based.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-07 21:26

Message:
Logged In: YES 
user_id=31392

This looks like a bug to me, too.  I think a non-string attr
argument
to getattr()  should raise TypeError.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-05-04 04:11

Message:
Logged In: YES 
user_id=6656

But consider this:

>>> getattr({},1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: attribute name must be string
>>> getattr({},1,"e")
'e'

or

>>> getattr(None,u"\343","e")
'e'
>>> getattr(None,u"\343")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII encoding error: ordinal not in range(128)

Here's a possible patch:

Index: bltinmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/bltinmodule.c,v
retrieving revision 2.200
diff -c -r2.200 bltinmodule.c
*** bltinmodule.c       2001/05/02 07:39:38     2.200
--- bltinmodule.c       2001/05/04 11:09:35
***************
*** 845,850 ****
--- 845,854 ----
  The globals and locals are dictionaries, defaulting to the
current\n\
  globals and locals.  If only globals is given, locals
defaults to it.";
  
+ /* Internal API needed by builtin_getattr(): */
+ extern 
+ PyObject *_PyUnicode_AsDefaultEncodedString(PyObject *unicode,
+                                 const char *errors);
  
  static PyObject *
  builtin_getattr(PyObject *self, PyObject *args)
***************
*** 854,859 ****
--- 858,874 ----
  
        if (!PyArg_ParseTuple(args, "OO|O:getattr", &v,
&name, &dflt))
                return NULL;
+       if (PyUnicode_Check(name)) {
+               name =
_PyUnicode_AsDefaultEncodedString(name, NULL);
+               if (name == NULL)
+                       return NULL;
+       } 
+       else if (!PyString_Check(name)) {
+               PyErr_Format(PyExc_TypeError,
+            "getattr: attribute name must be string, not
\%.500s\",
+                            name->ob_type->tp_name);
+               return NULL;
+       }
        result = PyObject_GetAttr(v, name);
        if (result == NULL && dflt != NULL) {
                PyErr_Clear();

... though by the time you've done all that, there's not
much point in calling PyObject_GetAttr at all...

OTOH, this changes behaviour, so maybe one should just
clarify this in the docs.

----------------------------------------------------------------------

Comment By: Chris Cogdon (chriscog)
Date: 2001-05-03 17:55

Message:
Logged In: YES 
user_id=67116

Looks like an attribute error to me. consider this:

>>> getattr (t,fred,"thingy")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: There is no variable named 'fred'

Ie, in your own example, it couldn't find an attribute '1' 
in the class, even if its an integer attribute (which is 
only obtainable using getattr/setattr). That's exactly what 
AttributeError is

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420304&group_id=5470


From noreply@sourceforge.net  Wed May 23 05:58:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 21:58:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-426539 ] Math-module lacks some docs and funcs
Message-ID: <E152Qie-0001Y4-00@usw-sf-web3.sourceforge.net>

Bugs item #426539, was updated on 2001-05-22 21:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426539&group_id=5470

Category: Extension Modules
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Rikard Bosnjakovic (bosna)
Assigned to: Nobody/Anonymous (nobody)
Summary: Math-module lacks some docs and funcs

Initial Comment:
>>> import math
>>> print math.cos.__doc__
cos(x)

Return the cosine of x.


1. That doc-string is not very sufficient, since it
does not tell whether x should be in radians or
degrees. Same goes with sin, asin, acos and the rest of
the degree-functions.

2. ceil() and floor() could have some more information
of what the functions does. Not all users have taken
math-courses and know about them.

3. Add a degrees(x) and radians(x) that converts "x" to
degrees (from a radian argument) and to radians (from a
degree argument) respectively, it's pretty useful.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426539&group_id=5470


From noreply@sourceforge.net  Wed May 23 05:59:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 22 May 2001 21:59:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-426473 ] Need docs for writing PyUnit-based tests
Message-ID: <E152QkD-0008VU-00@usw-sf-web1.sourceforge.net>

Bugs item #426473, was updated on 2001-05-22 15:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426473&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Need docs for writing PyUnit-based tests

Initial Comment:
The Lib/test/README file does not describe how to use
PyUnit for Python regression tests, and conventions
used in doing so.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-22 21:59

Message:
Logged In: YES 
user_id=3066

Added information on using doctest and PyUnit to Lib/test/README revision 1.7.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426473&group_id=5470


From noreply@sourceforge.net  Wed May 23 10:20:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 02:20:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Unicode Build Prob.
Message-ID: <E152Uoe-0001fK-00@usw-sf-web2.sourceforge.net>

Bugs item #420416, was updated on 2001-05-01 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Schinckel (schinckel)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Python for BeOS/PPC Unicode Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-23 02:20

Message:
Logged In: YES 
user_id=38388

I've uploaded Matthew's config files to SF. Perhaps some
Metroworks wizard could also take a look at these ?!

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 03:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 02:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 04:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470


From noreply@sourceforge.net  Wed May 23 19:27:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 11:27:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-426711 ] Floating Point Curiosity in Python 2.1
Message-ID: <E152dMK-0004tj-00@usw-sf-web1.sourceforge.net>

Bugs item #426711, was updated on 2001-05-23 11:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426711&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Graham (danielgraham)
Assigned to: Nobody/Anonymous (nobody)
Summary: Floating Point Curiosity in Python 2.1

Initial Comment:
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on
linux 2

In python 2.1	in python 1.5.2
>>> .10*103
10.300000000000001	10.3	
>>>round(.10*103,2)
10.300000000000001	10.3
>>>round(.10*103.123,1)
10.300000000000001	10.3
>>>round(.10*103.123,2)
10.31			10.31
>>>round(.0*103.123,3)
10.311999999999999	10.312


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426711&group_id=5470


From noreply@sourceforge.net  Wed May 23 19:33:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 11:33:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-426711 ] Floating Point Curiosity in Python 2.1
Message-ID: <E152dS3-0003OG-00@usw-sf-web3.sourceforge.net>

Bugs item #426711, was updated on 2001-05-23 11:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426711&group_id=5470

Category: None
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Daniel Graham (danielgraham)
Assigned to: Nobody/Anonymous (nobody)
Summary: Floating Point Curiosity in Python 2.1

Initial Comment:
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on
linux 2

In python 2.1	in python 1.5.2
>>> .10*103
10.300000000000001	10.3	
>>>round(.10*103,2)
10.300000000000001	10.3
>>>round(.10*103.123,1)
10.300000000000001	10.3
>>>round(.10*103.123,2)
10.31			10.31
>>>round(.0*103.123,3)
10.311999999999999	10.312


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-23 11:33

Message:
Logged In: YES 
user_id=31435

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for a detailed example:

http://www.python.org/cgi-bin/moinmoin/RepresentationError


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426711&group_id=5470


From noreply@sourceforge.net  Wed May 23 19:55:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 11:55:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-426711 ] Floating Point Curiosity in Python 2.1
Message-ID: <E152dnA-0007pa-00@usw-sf-web2.sourceforge.net>

Bugs item #426711, was updated on 2001-05-23 11:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426711&group_id=5470

Category: None
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Daniel Graham (danielgraham)
Assigned to: Nobody/Anonymous (nobody)
Summary: Floating Point Curiosity in Python 2.1

Initial Comment:
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on
linux 2

In python 2.1	in python 1.5.2
>>> .10*103
10.300000000000001	10.3	
>>>round(.10*103,2)
10.300000000000001	10.3
>>>round(.10*103.123,1)
10.300000000000001	10.3
>>>round(.10*103.123,2)
10.31			10.31
>>>round(.0*103.123,3)
10.311999999999999	10.312


----------------------------------------------------------------------

>Comment By: Daniel Graham (danielgraham)
Date: 2001-05-23 11:55

Message:
Logged In: YES 
user_id=20306

I wasn't surprised by the "representation error" but by the
behavior of the function "round".

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-23 11:33

Message:
Logged In: YES 
user_id=31435

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for a detailed example:

http://www.python.org/cgi-bin/moinmoin/RepresentationError


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426711&group_id=5470


From noreply@sourceforge.net  Wed May 23 20:17:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 12:17:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-426711 ] Floating Point Curiosity in Python 2.1
Message-ID: <E152e8l-00084L-00@usw-sf-web2.sourceforge.net>

Bugs item #426711, was updated on 2001-05-23 11:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426711&group_id=5470

Category: None
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Daniel Graham (danielgraham)
Assigned to: Nobody/Anonymous (nobody)
Summary: Floating Point Curiosity in Python 2.1

Initial Comment:
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on
linux 2

In python 2.1	in python 1.5.2
>>> .10*103
10.300000000000001	10.3	
>>>round(.10*103,2)
10.300000000000001	10.3
>>>round(.10*103.123,1)
10.300000000000001	10.3
>>>round(.10*103.123,2)
10.31			10.31
>>>round(.0*103.123,3)
10.311999999999999	10.312


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-23 12:17

Message:
Logged In: YES 
user_id=31435

There is no difference in the behavior of round().  Read 
the canned response again <wink>:  the only difference is 
the number of decimal digits in Python's default *display* 
of round()'s result.  Here in a recent Python:

>>> round(.10 * 103.123, 3)
10.311999999999999
>>> print round(.10 * 103.123, 3)
10.312
>>>

Same result, different display rounding, and that's all.  
1.5.2 also computed 10.311999999999999 for the result; but 
it didn't show you the truth by default.

----------------------------------------------------------------------

Comment By: Daniel Graham (danielgraham)
Date: 2001-05-23 11:55

Message:
Logged In: YES 
user_id=20306

I wasn't surprised by the "representation error" but by the
behavior of the function "round".

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-23 11:33

Message:
Logged In: YES 
user_id=31435

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for a detailed example:

http://www.python.org/cgi-bin/moinmoin/RepresentationError


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426711&group_id=5470


From noreply@sourceforge.net  Wed May 23 20:56:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 12:56:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-426735 ] Threaded Python program hangs
Message-ID: <E152ek9-0006SB-00@usw-sf-web1.sourceforge.net>

Bugs item #426735, was updated on 2001-05-23 12:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426735&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Threaded Python program hangs

Initial Comment:
import thread, os, time
thread.start_new_thread(os._exit, (1,))
time.sleep(1)
print "done"

The program never prints "done".

Python 2.1 (tummy RPM 2.1-4)
RedHat 6.2

strace of the main thread shows:
select(0, NULL, NULL, NULL, {1, 0})     = 0 (Timeout)
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
rt_sigsuspend([]
... Python completes the time.sleep() call, and then
hangs waiting something.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426735&group_id=5470


From noreply@sourceforge.net  Wed May 23 21:18:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 13:18:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-426740 ] pydoc: check bases for doc strings?
Message-ID: <E152f50-0000Gw-00@usw-sf-web2.sourceforge.net>

Bugs item #426740, was updated on 2001-05-23 13:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426740&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 2
Submitted By: Skip Montanaro (montanaro)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc: check bases for doc strings?

Initial Comment:
Given the following class hierarchy:

class A:
  def foo(self):
    "do the foo"
    pass

class B(A):
  def foo(self):
    pass

class C(B):
  def foo(self):
    "do the foo in C"
    pass

if you ask pydoc for help about A or C you will get the
corresponding doc string.  If you ask for help about B,
however, you see no documentation.  Would be kinda nice
if pydoc.help(B) displayed "do the foo" as the doc
string for B.foo.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426740&group_id=5470


From noreply@sourceforge.net  Wed May 23 21:18:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 13:18:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-426711 ] Floating Point Curiosity in Python 2.1
Message-ID: <E152f5n-0000H6-00@usw-sf-web2.sourceforge.net>

Bugs item #426711, was updated on 2001-05-23 11:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426711&group_id=5470

Category: None
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Daniel Graham (danielgraham)
Assigned to: Nobody/Anonymous (nobody)
Summary: Floating Point Curiosity in Python 2.1

Initial Comment:
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on
linux 2

In python 2.1	in python 1.5.2
>>> .10*103
10.300000000000001	10.3	
>>>round(.10*103,2)
10.300000000000001	10.3
>>>round(.10*103.123,1)
10.300000000000001	10.3
>>>round(.10*103.123,2)
10.31			10.31
>>>round(.0*103.123,3)
10.311999999999999	10.312


----------------------------------------------------------------------

>Comment By: Daniel Graham (danielgraham)
Date: 2001-05-23 13:18

Message:
Logged In: YES 
user_id=20306

OK, I finally get the point.  Thanks

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-23 12:17

Message:
Logged In: YES 
user_id=31435

There is no difference in the behavior of round().  Read 
the canned response again <wink>:  the only difference is 
the number of decimal digits in Python's default *display* 
of round()'s result.  Here in a recent Python:

>>> round(.10 * 103.123, 3)
10.311999999999999
>>> print round(.10 * 103.123, 3)
10.312
>>>

Same result, different display rounding, and that's all.  
1.5.2 also computed 10.311999999999999 for the result; but 
it didn't show you the truth by default.

----------------------------------------------------------------------

Comment By: Daniel Graham (danielgraham)
Date: 2001-05-23 11:55

Message:
Logged In: YES 
user_id=20306

I wasn't surprised by the "representation error" but by the
behavior of the function "round".

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-23 11:33

Message:
Logged In: YES 
user_id=31435

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for a detailed example:

http://www.python.org/cgi-bin/moinmoin/RepresentationError


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426711&group_id=5470


From noreply@sourceforge.net  Thu May 24 07:27:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 23 May 2001 23:27:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-426866 ] urllib and socket fail with MS proxy
Message-ID: <E152oaW-00044Q-00@usw-sf-web3.sourceforge.net>

Bugs item #426866, was updated on 2001-05-23 23:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426866&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib and socket fail with MS proxy 

Initial Comment:
Both urllib and socket fail to work with MS proxy with 
winsock client install.

urllib's proxy detection will correctly detect the 
existing of the proxy server but fail to work with it. 
It will return an empty page when an read() is issued.

socket will report 1006 winsock error.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426866&group_id=5470


From noreply@sourceforge.net  Thu May 24 09:56:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 24 May 2001 01:56:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-426892 ] grid_location class at the wrong place
Message-ID: <E152qvK-0007kW-00@usw-sf-web2.sourceforge.net>

Bugs item #426892, was updated on 2001-05-24 01:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426892&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: grid_location class at the wrong place

Initial Comment:
grid_location is a method for the master, and thus it
should be in Misc instead of Grid.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426892&group_id=5470


From noreply@sourceforge.net  Thu May 24 17:00:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 24 May 2001 09:00:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-426960 ] fork problem with Python-2.1
Message-ID: <E152xXH-0000Q0-00@usw-sf-web1.sourceforge.net>

Bugs item #426960, was updated on 2001-05-24 09:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426960&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Steinhoff (arminsteinhoff)
Assigned to: Nobody/Anonymous (nobody)
Summary: fork problem with Python-2.1

Initial Comment:

I have a strange problem with Python2.1 running QNX6.
The test script test_fork1.py returns with following result:

# python -t test_fork1.py
/* sys.path include in script ... */
['', '/usr/local/lib/python2.1', '/usr/local/lib/python2.1/Lib/lib-tk',
'/usr/local/lib/python2.1/lib/python2.1', '/usr/local/
lib/python2.1/lib/python2.1/plat-qnx6',
'/usr/local/lib/python2.1/lib/python2.1/lib-tk',
'/usr/local/lib/python2.1/lib/python2 .1/lib-dynload']
Traceback (most recent call last):
  File "test_fork1.py", line 76, in ?
    main()
  File "test_fork1.py", line 55, in main
    cpid = os.fork()
OSError: [Errno 89] Function not implemented

----------------------------------------------------------------------
That's very strange ... because it works in the interactive mode =:-(
----------------------------------------------------------------------

# python
Python 2.1 (#16, May 11 2001, 18:37:57)
[GCC 2.95.2 19991024 (release)] on qnx6
Type "copyright", "credits" or "license" for more information.
>>> import sys, os
>>>sys.path
['', '/usr/local/lib/python2.1', '/usr/local/lib/python2.1/Lib/lib-tk',
'/usr/local/lib/python2.1/lib/python2.1',
'/usr/local/lib/python2.1/lib/python2.1/plat-qnx6',
'/usr/local/lib/python2.1/lib/python2.1/lib-tk',
'/usr/local/lib/python2.1/lib/python2 .1/lib-dynload']
>>>
>>> os.fork
<built-in function fork>
>>> os.fork()
6512990

Any ideas where to look?

Armin



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426960&group_id=5470


From noreply@sourceforge.net  Thu May 24 20:40:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 24 May 2001 12:40:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-427036 ] [66.6] != [66.599999999999994]?
Message-ID: <E1530xz-0005vA-00@usw-sf-web2.sourceforge.net>

Bugs item #427036, was updated on 2001-05-24 12:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427036&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: David Waggle (darkmo0d)
Assigned to: Nobody/Anonymous (nobody)
Summary: [66.6] != [66.599999999999994]?

Initial Comment:
=darkmo0d=[14:52:28]darkmo0d<$> python -c 'a=[66.6]
;print a'
[66.599999999999994]


should this occur? seems like it could cause a serious
problem, provided this is not specific to my machine.
Which is:

x86 Linux Kernel 2.4.5-pre1
Python 2.1
Celeron 433mHz with 256MB SDRAM



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427036&group_id=5470


From noreply@sourceforge.net  Thu May 24 21:00:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 24 May 2001 13:00:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-427036 ] [66.6] != [66.599999999999994]?
Message-ID: <E1531HE-0005cd-00@usw-sf-web3.sourceforge.net>

Bugs item #427036, was updated on 2001-05-24 12:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427036&group_id=5470

Category: Python Interpreter Core
>Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: David Waggle (darkmo0d)
Assigned to: Nobody/Anonymous (nobody)
Summary: [66.6] != [66.599999999999994]?

Initial Comment:
=darkmo0d=[14:52:28]darkmo0d<$> python -c 'a=[66.6]
;print a'
[66.599999999999994]


should this occur? seems like it could cause a serious
problem, provided this is not specific to my machine.
Which is:

x86 Linux Kernel 2.4.5-pre1
Python 2.1
Celeron 433mHz with 256MB SDRAM



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-24 13:00

Message:
Logged In: YES 
user_id=31435

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for a detailed example:

http://www.python.org/cgi-bin/moinmoin/RepresentationError


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427036&group_id=5470


From noreply@sourceforge.net  Thu May 24 21:34:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 24 May 2001 13:34:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-427060 ] pydoc: inconsistent behavior for imports
Message-ID: <E1531oi-00060E-00@usw-sf-web3.sourceforge.net>

Bugs item #427060, was updated on 2001-05-24 13:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427060&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bryan Nollett (nollett)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc: inconsistent behavior for imports

Initial Comment:
Consider a module mymod.py containing the following two
import statements:

from md5 import new
from base64 import decode

Running "pydoc mymod" yields a helpfile containing a
description of function new from md5 but not function
decode from base64.  The distinction seems to be that
new is a built-in function while decode is a "plain"
function.  From a user's perspective however, this
seems to be very inconsistent.

>From a very brief glance at pydoc.py, this distinction
appears to be an intentional one, but it is not clear
to me why this behavior would be desirable, at least in
this (very typical?) example.

As a further example, consider mymod.py containing a
different import statement:

from Numeric import array, arange, resize, zeros

Some functions in Numeric are built-ins and others
"plain" functions. So here "pydoc mymod" would include
documentation for array and zeros (since they happen to
be implemented as built-ins) and not arange or resize.

I think pydoc follows a rule something like this:

imported classes -- not documented
imported functions -- documented only if built-in
imported "data" -- documented (with obvious exceptions)

Perhaps the default behavior should be that *none* of
the imported symbols be documented?  (If all are
documented, this makes pydoc much less usable with
Numeric or Tkinter where the "from Tkinter import *"
idiom is often a necessary evil.)  I can see cases
where one would like imported symbols to be documented
but do not see a mechanism currently in place to
distinguish between the two uses.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427060&group_id=5470


From noreply@sourceforge.net  Thu May 24 22:10:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 24 May 2001 14:10:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-427073 ] DLINCLDIR defined incorrectly
Message-ID: <E1532NE-0005ON-00@usw-sf-web1.sourceforge.net>

Bugs item #427073, was updated on 2001-05-24 14:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427073&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: DLINCLDIR defined incorrectly

Initial Comment:
On my Linux system (vanilla Mandrake 8.0),
.../Python/Makefile winds up defining DLINCLDIR as

    DLINCLDIR=	/

While it should should be fairly innocuous, it can't
possibly be correct.  If it's going to default to
something, I suggest it default to "." instead (see
configure.in).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427073&group_id=5470


From noreply@sourceforge.net  Thu May 24 22:23:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 24 May 2001 14:23:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-427036 ] [66.6] != [66.599999999999994]?
Message-ID: <E1532a6-000758-00@usw-sf-web2.sourceforge.net>

Bugs item #427036, was updated on 2001-05-24 12:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427036&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: David Waggle (darkmo0d)
Assigned to: Nobody/Anonymous (nobody)
Summary: [66.6] != [66.599999999999994]?

Initial Comment:
=darkmo0d=[14:52:28]darkmo0d<$> python -c 'a=[66.6]
;print a'
[66.599999999999994]


should this occur? seems like it could cause a serious
problem, provided this is not specific to my machine.
Which is:

x86 Linux Kernel 2.4.5-pre1
Python 2.1
Celeron 433mHz with 256MB SDRAM



----------------------------------------------------------------------

>Comment By: David Waggle (darkmo0d)
Date: 2001-05-24 14:23

Message:
Logged In: YES 
user_id=206710

The code/output that follows is what results from using the
python tutorial.
So, I grasp the concept of the binary floating point
"situation". No problem. But it took all day and a bug
report to elicit canned-text. So not only am I expericencing
a "RepresentationError", but so is the python tutorial. No
where in chap/sec 5.1 on pp 29-30 does it mention this and
it is quite confusing to a newbie when the teacher's answers
and the student's answers do not match. According to the
tutorial this code/output should be what I see when passed
through the interpreter:

>>>a = [66.6, 333, 333, 1, 1234.5]
>>>a
[66.6, 333, 333, 1, 1234.5]

but I see:

Python 2.1 (#1, May 24 2001, 09:28:32) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> a = [66.6, 333, 333, 1, 1234.5]
>>> a
[66.599999999999994, 333, 333, 1, 1234.5]
>>> str(a)
'[66.599999999999994, 333, 333, 1, 1234.5]'
>>> str(a[0])
'66.6'
>>> str(a[0:3])
'[66.599999999999994, 333, 333]'
>>> str(a[0:1])
'[66.599999999999994]'
>>> str(a[0:])
'[66.599999999999994, 333, 333, 1, 1234.5]'

So point taken and logged. So if you know the guy who wrote
the docs, or are the guy who wrote the docs: Take my point
into consideration. Docs can have bugs, too. 




----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-24 13:00

Message:
Logged In: YES 
user_id=31435

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for a detailed example:

http://www.python.org/cgi-bin/moinmoin/RepresentationError


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427036&group_id=5470


From noreply@sourceforge.net  Fri May 25 00:34:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 24 May 2001 16:34:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-427036 ] [66.6] != [66.599999999999994]?
Message-ID: <E1534cW-0008P2-00@usw-sf-web2.sourceforge.net>

Bugs item #427036, was updated on 2001-05-24 12:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427036&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: David Waggle (darkmo0d)
Assigned to: Nobody/Anonymous (nobody)
Summary: [66.6] != [66.599999999999994]?

Initial Comment:
=darkmo0d=[14:52:28]darkmo0d<$> python -c 'a=[66.6]
;print a'
[66.599999999999994]


should this occur? seems like it could cause a serious
problem, provided this is not specific to my machine.
Which is:

x86 Linux Kernel 2.4.5-pre1
Python 2.1
Celeron 433mHz with 256MB SDRAM



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-24 16:34

Message:
Logged In: YES 
user_id=31435

As I mentioned in email, the tutorial has already been 
repaired but the new version has not yet been released (it 
will for be for 2.2).  Also (probably) adding a new 
Appendix (see your email).

Didn't understand the "all day" comment -- looks like you 
got a response in less than 2 hours (yes, a canned one, but 
had you searched the bug database you would have found many 
repetitions of this basic complaint on your own -- indeed, 
that's why a canned response exists <wink>).

----------------------------------------------------------------------

Comment By: David Waggle (darkmo0d)
Date: 2001-05-24 14:23

Message:
Logged In: YES 
user_id=206710

The code/output that follows is what results from using the
python tutorial.
So, I grasp the concept of the binary floating point
"situation". No problem. But it took all day and a bug
report to elicit canned-text. So not only am I expericencing
a "RepresentationError", but so is the python tutorial. No
where in chap/sec 5.1 on pp 29-30 does it mention this and
it is quite confusing to a newbie when the teacher's answers
and the student's answers do not match. According to the
tutorial this code/output should be what I see when passed
through the interpreter:

>>>a = [66.6, 333, 333, 1, 1234.5]
>>>a
[66.6, 333, 333, 1, 1234.5]

but I see:

Python 2.1 (#1, May 24 2001, 09:28:32) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> a = [66.6, 333, 333, 1, 1234.5]
>>> a
[66.599999999999994, 333, 333, 1, 1234.5]
>>> str(a)
'[66.599999999999994, 333, 333, 1, 1234.5]'
>>> str(a[0])
'66.6'
>>> str(a[0:3])
'[66.599999999999994, 333, 333]'
>>> str(a[0:1])
'[66.599999999999994]'
>>> str(a[0:])
'[66.599999999999994, 333, 333, 1, 1234.5]'

So point taken and logged. So if you know the guy who wrote
the docs, or are the guy who wrote the docs: Take my point
into consideration. Docs can have bugs, too. 




----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-24 13:00

Message:
Logged In: YES 
user_id=31435

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for a detailed example:

http://www.python.org/cgi-bin/moinmoin/RepresentationError


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427036&group_id=5470


From noreply@sourceforge.net  Fri May 25 14:52:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 25 May 2001 06:52:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-420851 ] Missing docs for iteration support.
Message-ID: <E153I0g-00072k-00@usw-sf-web1.sourceforge.net>

Bugs item #420851, was updated on 2001-05-02 13:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420851&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Missing docs for iteration support.

Initial Comment:
Documentation is needed for the iteration support.  At this time, the following things are missing docs:

- iter() function
- {}.iteritems(), .iterkeys(), .itervalues()
- tp_iter/tp_iternext
- __iter__() (ref. manual -- "Object Customization")

If you can think of other aspects of this that I've missed, please note them as comments on this bug report so I can address these (or at least keep track of these) in a single place.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-25 06:52

Message:
Logged In: YES 
user_id=3066

Docs for {}.iteritems(), {}.iterkeys(), and {}.itervalues()
checked in as Doc/lib/libstdtypes.tex revision 1.59.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420851&group_id=5470


From noreply@sourceforge.net  Fri May 25 18:37:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 25 May 2001 10:37:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E153LWn-0002Pg-00@usw-sf-web1.sourceforge.net>

Bugs item #427345, was updated on 2001-05-25 10:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer fix for Windows

Initial Comment:
CGIHTTPServer.py in the Python 2.1 library needs two 
changes to the popen2 section in order to support 
binary data and to avoid buffering problems under 
Windows. The complete code block is shown at the end 
of this message. The two changed lines are:
cmdline = "%s -u %s" % (interp, cmdline)
fi, fo = os.popen2(cmdline, 'b')

I've tested this under Windows 2000 Pro and binary 
file uploads now work, however more extensive tests 
should probably be done.

It appears there is another socket-related problem 
and/or end-of-line conversion error that occurs when 
using Internet Explorer 5.x and BASEHTTPServer with 
CGIHTTPServer on the same machine. I'm still 
investigating that issue.

Finally, I have done a small rewrite of 
CGIHTTPServer.py to simplify subclassing it to support 
running CGIs in any or all directories and using other 
file extensions such as .cgi. The maintainer for the 
current file should email me about the changes to see 
whether they want to update the official library file. 
I didn't post it here since it needs more tweaking

ka
---
CGIHTTPServer.p fixes...
elif self.have_popen2:
    # Windows -- use popen2 to create a subprocess
    import shutil
    os.environ.update(env)
    cmdline = scriptfile
    if self.is_python(scriptfile):
        interp = sys.executable
        if interp.lower().endswith("w.exe"):
            # On Windows, use python.exe, not 
python.exe
            interp = interp[:-5] = interp[-4:]
        cmdline = "%s -u %s" % (interp, cmdline)
    if '=' not in query and '"' not in query:
        cmdline = '%s "%s"' % (cmdline, query)
    self.log_error("command: %s", cmdline)
    try:
        nbytes = int(length)
    except:
        nbytes = 0
    fi, fo = os.popen2(cmdline, 'b')
    if self.command.lower() == "post" and nbytes > 0:
        data = self.rfile.read(nbytes)
        fi.write(data)
    fi.close()
    shutil.copyfileobj(fo, self.wfile)
    sts = fo.close()
    if sts:
        self.log_error("CGI script exit status %#x", 
sts)
    else:
        self.log_error("CGI script exited OK")


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470


From noreply@sourceforge.net  Sat May 26 11:13:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 26 May 2001 03:13:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-427524 ] path formatter between unix and windows
Message-ID: <E153b54-0006lt-00@usw-sf-web1.sourceforge.net>

Bugs item #427524, was updated on 2001-05-26 03:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427524&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: eXom (jkuan)
Assigned to: Nobody/Anonymous (nobody)
Summary: path formatter between unix and windows

Initial Comment:
Is it possible to have a function that converts the
unix path format into windows format, vice versa?

Or is there any function that does that already?

e.g.

def unix2winPath(pathName, drive='C:')
raise exception if there is any invalid character in
pathName


Thanks
Joe

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427524&group_id=5470


From noreply@sourceforge.net  Sat May 26 22:06:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 26 May 2001 14:06:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-427604 ] Lang Ref, section 2.4.5:  "digit" undef
Message-ID: <E153lGm-0003eo-00@usw-sf-web2.sourceforge.net>

Bugs item #427604, was updated on 2001-05-26 14:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427604&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Lang Ref, section 2.4.5:  "digit" undef

Initial Comment:
The grammar for  integer and longinteger given in
section 2.4.5 of the Language Reference is missing a
definition for  the "digit" term.

I think, the grammar should have a production like
this:
digit:  "0"..."9"

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427604&group_id=5470


From noreply@sourceforge.net  Sat May 26 22:30:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 26 May 2001 14:30:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-427604 ] Lang Ref, section 2.4.5:  "digit" undef
Message-ID: <E153ldu-0003sa-00@usw-sf-web2.sourceforge.net>

Bugs item #427604, was updated on 2001-05-26 14:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427604&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Lang Ref, section 2.4.5:  "digit" undef

Initial Comment:
The grammar for  integer and longinteger given in
section 2.4.5 of the Language Reference is missing a
definition for  the "digit" term.

I think, the grammar should have a production like
this:
digit:  "0"..."9"

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-26 14:30

Message:
Logged In: YES 
user_id=31435

"digit" is already defined, but in section 2.3 (Identifiers 
and keywords).

Fred, how much unbearable pain would it be to come with a 
(hyperlinked in HTML) grammar production index?  There are 
many cases where a production referenced in one section is 
defined in another, and it's very hard to find the 
definition whenever that occurs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427604&group_id=5470


From noreply@sourceforge.net  Sun May 27 13:36:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 27 May 2001 05:36:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-427698 ] objects with __eq__ are not hashable
Message-ID: <E153zm4-00030I-00@usw-sf-web2.sourceforge.net>

Bugs item #427698, was updated on 2001-05-27 05:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427698&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: objects with __eq__ are not hashable

Initial Comment:
The following code fails with Python2.1, on both SGI
IRIX 6.5 and Linux (Suse7.1)

class A:
    _name = 'AA'
    def __init__(self,name):
        self._name = name
    def __eq__(self,a):
        if (a._name == self._name):
            return 1
        else:
            return 0
    def __str__(self):
        return self._name

a = A('abc')

c = {}

c[a] = 1


===> 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unhashable instance

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427698&group_id=5470


From noreply@sourceforge.net  Sun May 27 22:26:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 27 May 2001 14:26:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-427698 ] objects with __eq__ are not hashable
Message-ID: <E15483G-0000aH-00@usw-sf-web2.sourceforge.net>

Bugs item #427698, was updated on 2001-05-27 05:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427698&group_id=5470

>Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: objects with __eq__ are not hashable

Initial Comment:
The following code fails with Python2.1, on both SGI
IRIX 6.5 and Linux (Suse7.1)

class A:
    _name = 'AA'
    def __init__(self,name):
        self._name = name
    def __eq__(self,a):
        if (a._name == self._name):
            return 1
        else:
            return 0
    def __str__(self):
        return self._name

a = A('abc')

c = {}

c[a] = 1


===> 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unhashable instance

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-27 14:26

Message:
Logged In: YES 
user_id=31435

If a class defines __eq__ or __cmp__, then for instances to 
be hashable it must also define __hash__.

Changed Category to Documentation and assigned to Fred.  
Ref Man Section 3.3.1 (Basic customization) explains this 
about __hash__, but only mentions __cmp__.  Guido should 
have changed this to include __eq__ too (i.e., everywhere 
__hash__ mentions __cmp__() now it should add "or __eq__
()").

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427698&group_id=5470


From noreply@sourceforge.net  Sun May 27 23:00:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 27 May 2001 15:00:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-427783 ] Lang Ref  section 4.1 s/is/in/
Message-ID: <E1548aO-0007mM-00@usw-sf-web1.sourceforge.net>

Bugs item #427783, was updated on 2001-05-27 15:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427783&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Lang Ref  section 4.1 s/is/in/

Initial Comment:
The built-in namespace associated with the execution of
a code block is actually found by looking up the name
__builtins__ is its global namespace; 

I am pretty sure what's intended is
s/is its/in its/

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427783&group_id=5470


From noreply@sourceforge.net  Sun May 27 23:33:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 27 May 2001 15:33:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips
Message-ID: <E15496O-0001BH-00@usw-sf-web2.sourceforge.net>

Bugs item #410541, was updated on 2001-03-22 08:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: bdist builds bogus .zips

Initial Comment:
According to Thomas Heller: "... the resulting zip-file
from
'bdist --formats=zip' is unusable because it contains
filenames relative to
the root directory)"

Such paths may be OK for Unix (cd / and unzip it,
perhaps?), 
but isn't much good for Windows, where Python might be
installed anywhere.  


----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-27 15:33

Message:
Logged In: YES 
user_id=149084

gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.)

The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do?

It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages.

Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user.

GvR seems to be interested in making the install trees the same on Linux and Windows, that would help.

Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist?

If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 13:39

Message:
Logged In: YES 
user_id=11375

I expect no one will install from a .zip file on Unix.

Options:

1) Make both the .tgz and .zip relative to sys.prefix or 
something.
2) Make only the .zip relative.
3) Document this as being broken and forget about it.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470


From noreply@sourceforge.net  Mon May 28 11:59:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 May 2001 03:59:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Unicode Build Prob.
Message-ID: <E154Kk9-0007mf-00@usw-sf-web2.sourceforge.net>

Bugs item #420416, was updated on 2001-05-01 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Schinckel (schinckel)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Python for BeOS/PPC Unicode Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

----------------------------------------------------------------------

>Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-28 03:59

Message:
Logged In: YES 
user_id=193059

Here is the crux of my recent communications with Marc-Andre:

> Okay, I might be guessing a bit here but:
> 
> These programs are supposed to print the sizeof value.
> 
> They are not printing anything.
> 
> The only error being raised is:
> 
> ### mwcc Compiler Warning :
> #       }
> #       ^
> #   return value expected
> #----------------------------------------------------------
>     File "configure"; Line 2245
> #       while compiling "/boot/var/tmp/conftest.c"
> #----------------------------------------------------------
> 

Interesting: the compiler chokes on the missing return statement
in the test program rather than some other error. This is clearly
an autoconf bug and I'm not sure whether it can be fixed in 
Python.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-23 02:20

Message:
Logged In: YES 
user_id=38388

I've uploaded Matthew's config files to SF. Perhaps some
Metroworks wizard could also take a look at these ?!

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 03:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 02:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 04:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470


From noreply@sourceforge.net  Mon May 28 12:34:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 May 2001 04:34:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-420343 ] SystemError from tuple() builtin
Message-ID: <E154LID-00087n-00@usw-sf-web2.sourceforge.net>

Bugs item #420343, was updated on 2001-04-30 19:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420343&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Greg Chapman (glchapman)
Assigned to: Thomas Wouters (twouters)
Summary: SystemError from tuple() builtin

Initial Comment:
The following produces a SystemError under Python 2.1:

>>> class Test:
... 	def __init__(self):
... 		self.list = [1]
... 	def __len__(self):
... 		return 0
... 	def __getitem__(self, index):
... 		return self.list[index]
... 
>>> t = Test()
>>> tuple(t)
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
SystemError: C:\USERS\greg\PROG\CPP\PYTHON\Python-2.1
\Objects\tupleobject.c:506: bad argument to internal 
function

The problem is the call made by PySequence_Tuple to 
_PyTuple_Resize.  The above code results in an attempt 
to resize the empty tuple, the ref count of which is 
greater than 1.




----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2001-05-28 04:34

Message:
Logged In: YES 
user_id=34209

Hey, howlong has this bug been sitting here ?? Must be
something wrong with SF's bug mail stuff, because even
though this bug is assigned to me, I haven't seen it before
:P Anyway, fixing this, both for 2.2 and 2.1.1.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 22:01

Message:
Logged In: YES 
user_id=31435

Greg, list(f.xreadlines()) happens to work already under 
current CVS Python.  But note for the future that attaching 
a feature request to an unrelated bug report is a low-
probability way to get anyone to notice ...

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2001-04-30 19:41

Message:
Logged In: YES 
user_id=86307

Apropos this report and the recent python-dev 
thread "Iterators, map, xreadlines and docs":

>>> f = open(r"c:\autoexec.bat")
>>> l = list(f.xreadlines())
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: len() of unsized object

Admittedly, using xreadlines like this is silly, but it 
probably ought to work.  Both PySequence_Tuple and 
PySequence_List require len() (PySequence_Size) to succeed, 
even though they then pretty much ignore the returned 
length.  Perhaps they should be changed to be consistent 
with the changes in map.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420343&group_id=5470


From noreply@sourceforge.net  Mon May 28 13:20:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 May 2001 05:20:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E154M0l-0001Me-00@usw-sf-web1.sourceforge.net>

Bugs item #417845, was updated on 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-28 05:20

Message:
Logged In: YES 
user_id=198402

I have now started a project here concerning a SOCKS proxy 
written in python (PySocks). It is aimed mostly at people 
who use a windows box to share their internet connection 
and uses the threading server from the SocketServer module.

So it becomes VERY important to me to know of what will be 
done about this bug, in the next release/patch of Python 
library.

Could Mr Guido Vanrossum tell us about it? As for now I am 
forced to provide my patched version of SocketServer.py 
with my releases, what is not quite satisfactory. 
SocketServer is provided in the python distribution, so I'd 
rather tell "there is a patch for python..."

Well... In fact I forgot to put it in my first release, but 
I'll correct this this evening :)

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-20 12:06

Message:
Logged In: YES 
user_id=198402

Well I was wrong. We do need a "try" block to ensure the 
request is always correctly closed:

    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        try:
            self.RequestHandlerClass(request, 
client_address, self)
        finally:
            self.close_request(request)

This works better.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-13 09:09

Message:
Logged In: YES 
user_id=198402

I forgot to tell: I can not test if it does not break the 
forking server. I only have a windows platform available 
for now, and forking doesn't work in the python/win32 
environment for now as far as I know.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-13 08:51

Message:
Logged In: YES 
user_id=198402

What I propose can be applied without any compatibility 
issue.

I have tried something that seems to work, at least under 
windows (but it does need to be more fully tested though). 
Only 2 small modifications are required:

-1- In BaseServer, modification of the last line of 
handle_request:
<PRE>
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)

</PRE>
Note that only the indentation of the last has been 
modified so that the close_request is executed only if an 
exception occur.

Still we need to close the request after it had been 
processed, so here comes the second modification:
-2- Still in BaseServer:
<PRE>
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
</PRE>

There is already a try/except block in handle_request, so I 
thought it was not mandatory here to ensure the request was 
always closed.

Oh... I don't know how &lt;PRE&gt; tags are supported by 
the bugtracking system of sourceforge, so the samples I 
give may not appear as I want. This is quite a problem with 
python :/

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-12 15:46

Message:
Logged In: YES 
user_id=80200

hi there mr xlagraula,

yes, it would be a lot simpler... _if_ it wasn't
for the fact that this code is likely to already
be quite extensively used.  a possible 'upgrade'
path could be done by providing a... RequestHandler2
class, or some-such.

it would be neater to do this, or similar:
for t in self.thread_list:
    t.join(timeout=0.1)

which would join all threads, or you do if
stopped(), close_request.  i looked into
threads a bit more: join has a timeout,
and there is a stopped-detection function.

easy :)

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-12 14:18

Message:
Logged In: YES 
user_id=198402

Another solution could be to modify the behaviour of the 
server so that it would be the responsibility of 
the "child" thread/process to close the socket (except for 
the forking/threading error cases). Wouldn't it be simplier 
than child process tracking and thread tracking?

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-04 04:17

Message:
Logged In: YES 
user_id=80200

okay.  the forkingmixin code does a fork, records how many
children there are, and waits for one of them to exit,
before
proceeding - in particular, before proceeding to close
the request, etc.

... so why is not something similar done in ThreadingMixIn?

this kinda- tells me that thread-tracking is really needed,
in a similar way to that in forkingmixin.

----------------------------------------------------------------------

Comment By: Gregory P. Smith (greg)
Date: 2001-05-03 16:26

Message:
Logged In: YES 
user_id=413

Just a note of another casualty of this bug: I had to add
the mentioned dummy close_request method hack to our own
ThreadingMixIn class in mojo nation (in the sourceforge
mojonation project's evil module, see the
common/MojoNationHTTPServer.py file).  Without it, python
2.1 would always raise an exception in the request handler
as soon as it tried to call self.connection.makefile()
because self.connection had apparently already been closed! 
(its fd was always -1)


----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-02 01:41

Message:
Logged In: YES 
user_id=80200

hi there mr jrielh,

thank you very much for the details.  what i am having a
little difficulty with is, what's the difference between
this and python 2.0 SocketServer.py?

more specifically, i'm looking at python 2.0 SocketServer.py
and, whilst i'm not a Threads expert, i see a t.start() but
no t.join().  i've been looking at the Queue example code in
the test method of threads.py, and start() is called on
every thread, followed by join() on every thread.  join
waits for the thread to finish, yes?

so... if that's the case, then python 2.0 SocketServer.py
should suffer from
exactly the same behaviour, yes?  unless python behaves
ever-so-slightly differently (timing issues?) when you have
an extra base class like this,
with the consequence that close_request() is more likely to
be called
before ThreadingMixIn.process_request().

?

----------------------------------------------------------------------

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:20

Message:
Logged In: YES 
user_id=22448

This is related to bug #419873.
The problem is not specifically in the ThreadingMixin
specifically, but where BaseServer calls close_request()
after calling process_request().  In the threading mixin,
process_request() spins the thread and returns, causing the
request socket to be invalidated while the thread is still
running.  The fix given above will keep the socket valid
while the thread is running, but may cause the socket to not
close properly (my threads generally close the socket when
they are done anyway.)

----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



----------------------------------------------------------------------

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470


From noreply@sourceforge.net  Mon May 28 14:18:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 May 2001 06:18:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-420343 ] SystemError from tuple() builtin
Message-ID: <E154MuP-0000hO-00@usw-sf-web2.sourceforge.net>

Bugs item #420343, was updated on 2001-04-30 19:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420343&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Greg Chapman (glchapman)
>Assigned to: Moshe Zadka (moshez)
Summary: SystemError from tuple() builtin

Initial Comment:
The following produces a SystemError under Python 2.1:

>>> class Test:
... 	def __init__(self):
... 		self.list = [1]
... 	def __len__(self):
... 		return 0
... 	def __getitem__(self, index):
... 		return self.list[index]
... 
>>> t = Test()
>>> tuple(t)
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
SystemError: C:\USERS\greg\PROG\CPP\PYTHON\Python-2.1
\Objects\tupleobject.c:506: bad argument to internal 
function

The problem is the call made by PySequence_Tuple to 
_PyTuple_Resize.  The above code results in an attempt 
to resize the empty tuple, the ref count of which is 
greater than 1.




----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2001-05-28 06:18

Message:
Logged In: YES 
user_id=34209

There, fixed for 2.1.1 and 2.2. (revisions 2.50 and
2.48.4.1)

Moshe'll have to decide whether he wants the fix for 2.0.1
(there is no big reason not to, but I don't know where he is
with 2.0.1, so I don't want to check it in without his
okay.) Bug reassigned to Moshe for that purpose.


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-05-28 04:34

Message:
Logged In: YES 
user_id=34209

Hey, howlong has this bug been sitting here ?? Must be
something wrong with SF's bug mail stuff, because even
though this bug is assigned to me, I haven't seen it before
:P Anyway, fixing this, both for 2.2 and 2.1.1.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 22:01

Message:
Logged In: YES 
user_id=31435

Greg, list(f.xreadlines()) happens to work already under 
current CVS Python.  But note for the future that attaching 
a feature request to an unrelated bug report is a low-
probability way to get anyone to notice ...

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2001-04-30 19:41

Message:
Logged In: YES 
user_id=86307

Apropos this report and the recent python-dev 
thread "Iterators, map, xreadlines and docs":

>>> f = open(r"c:\autoexec.bat")
>>> l = list(f.xreadlines())
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: len() of unsized object

Admittedly, using xreadlines like this is silly, but it 
probably ought to work.  Both PySequence_Tuple and 
PySequence_List require len() (PySequence_Size) to succeed, 
even though they then pretty much ignore the returned 
length.  Perhaps they should be changed to be consistent 
with the changes in map.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420343&group_id=5470


From noreply@sourceforge.net  Mon May 28 14:20:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 May 2001 06:20:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-420343 ] SystemError from tuple() builtin
Message-ID: <E154Mww-0000j4-00@usw-sf-web2.sourceforge.net>

Bugs item #420343, was updated on 2001-04-30 19:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420343&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Greg Chapman (glchapman)
Assigned to: Moshe Zadka (moshez)
Summary: SystemError from tuple() builtin

Initial Comment:
The following produces a SystemError under Python 2.1:

>>> class Test:
... 	def __init__(self):
... 		self.list = [1]
... 	def __len__(self):
... 		return 0
... 	def __getitem__(self, index):
... 		return self.list[index]
... 
>>> t = Test()
>>> tuple(t)
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
SystemError: C:\USERS\greg\PROG\CPP\PYTHON\Python-2.1
\Objects\tupleobject.c:506: bad argument to internal 
function

The problem is the call made by PySequence_Tuple to 
_PyTuple_Resize.  The above code results in an attempt 
to resize the empty tuple, the ref count of which is 
greater than 1.




----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2001-05-28 06:20

Message:
Logged In: YES 
user_id=34209

(Eh... I should have said: revisions 2.50 and 2.48.4.1 of
Objects/tupleobject.c)


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-05-28 06:18

Message:
Logged In: YES 
user_id=34209

There, fixed for 2.1.1 and 2.2. (revisions 2.50 and
2.48.4.1)

Moshe'll have to decide whether he wants the fix for 2.0.1
(there is no big reason not to, but I don't know where he is
with 2.0.1, so I don't want to check it in without his
okay.) Bug reassigned to Moshe for that purpose.


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-05-28 04:34

Message:
Logged In: YES 
user_id=34209

Hey, howlong has this bug been sitting here ?? Must be
something wrong with SF's bug mail stuff, because even
though this bug is assigned to me, I haven't seen it before
:P Anyway, fixing this, both for 2.2 and 2.1.1.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-07 22:01

Message:
Logged In: YES 
user_id=31435

Greg, list(f.xreadlines()) happens to work already under 
current CVS Python.  But note for the future that attaching 
a feature request to an unrelated bug report is a low-
probability way to get anyone to notice ...

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2001-04-30 19:41

Message:
Logged In: YES 
user_id=86307

Apropos this report and the recent python-dev 
thread "Iterators, map, xreadlines and docs":

>>> f = open(r"c:\autoexec.bat")
>>> l = list(f.xreadlines())
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: len() of unsized object

Admittedly, using xreadlines like this is silly, but it 
probably ought to work.  Both PySequence_Tuple and 
PySequence_List require len() (PySequence_Size) to succeed, 
even though they then pretty much ignore the returned 
length.  Perhaps they should be changed to be consistent 
with the changes in map.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420343&group_id=5470


From noreply@sourceforge.net  Mon May 28 14:30:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 May 2001 06:30:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-410608 ] popen with threads
Message-ID: <E154N6H-0002NK-00@usw-sf-web1.sourceforge.net>

Bugs item #410608, was updated on 2001-03-22 13:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410608&group_id=5470

Category: Threads
>Group: Irreproducible
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Thomas Wouters (twouters)
Summary: popen with threads

Initial Comment:
This code generate a error

##########################
import threading
import os

class TestPopen( threading.Thread ):

   def run( self ):
      while 1:
         f = os.popen( "ls -l /" )
         lines = f.read()
         f.close()

if __name__ == "__main__":
   for i in range(50):
      t = TestPopen()
      t.start()
###########################

it eventually dies w/ IOErrors in the f.close() calls.

My system is:
Linux RedHat 6.2
Python 1.5.2
I tested in Python 2.0 and the same error occur.




----------------------------------------------------------------------

>Comment By: Thomas Wouters (twouters)
Date: 2001-05-28 06:30

Message:
Logged In: YES 
user_id=34209

It's been long enough... Closing this bug with 'works for
me', since that's what it does.

----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-04-05 14:34

Message:
Logged In: YES 
user_id=34209

I cannot reproduce this with 2.1-CVS, but I am not able to
test this on RedHat 6.2 right now. It could be a limits
problem. If the original submittor is reading this: try
doing an 'unlimit' or 'ulimit -a' before running the script.
If it still crashes, please paste one of the tracebacks. I
do get IOErrors and some weird crashes when I run the above
script with lower filedescriptor limits, but not on the
f.close() call. 


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-04 19:33

Message:
Logged In: YES 
user_id=31435

Thomas, you want to play with this on Linux?  I already 
gave my best guesses on c.l.py; there's no hope running 
popen stress tests on Win9x, as whether even one popen 
works there one time is a crapshoot.  I assume Mr./Ms. 
Anonymous is running out of system resources, but even if 
so that leaves the question of whether that's 1.5.2's or 
Linux's fault (if it works under current CVS, we can assume 
it was 1.5.2's fault).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410608&group_id=5470


From noreply@sourceforge.net  Mon May 28 17:03:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 May 2001 09:03:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-427985 ] optional "listen" parameter in asyncore
Message-ID: <E154PUK-00056h-00@usw-sf-web3.sourceforge.net>

Bugs item #427985, was updated on 2001-05-28 09:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427985&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: optional "listen" parameter in asyncore

Initial Comment:
Python Docs.

Library Reference for Python 2.1

Asyncore module, pag 312.

"Listen" parameter "backlog" is 'typesetted' like an
optional parameter, but the parameter is not optional.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427985&group_id=5470


From noreply@sourceforge.net  Mon May 28 17:34:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 May 2001 09:34:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-426740 ] pydoc: check bases for doc strings?
Message-ID: <E154PyA-0004sX-00@usw-sf-web1.sourceforge.net>

Bugs item #426740, was updated on 2001-05-23 13:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426740&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 2
Submitted By: Skip Montanaro (montanaro)
Assigned to: Ka-Ping Yee (ping)
Summary: pydoc: check bases for doc strings?

Initial Comment:
Given the following class hierarchy:

class A:
  def foo(self):
    "do the foo"
    pass

class B(A):
  def foo(self):
    pass

class C(B):
  def foo(self):
    "do the foo in C"
    pass

if you ask pydoc for help about A or C you will get the
corresponding doc string.  If you ask for help about B,
however, you see no documentation.  Would be kinda nice
if pydoc.help(B) displayed "do the foo" as the doc
string for B.foo.


----------------------------------------------------------------------

Comment By: Bastian Kleineidam (calvin)
Date: 2001-05-28 09:34

Message:
Logged In: YES 
user_id=9205

No, please dont do this, IMO its the wrong way.
B.foo() is different from A.foo(), so it needs
a different doc string.
Just imagine I document A.foo() with "do the foo in A",
then your scheme is not working.

Bastian

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426740&group_id=5470


From noreply@sourceforge.net  Tue May 29 02:47:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 May 2001 18:47:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-426735 ] [Linux] Threaded Python program hangs
Message-ID: <E154Ybh-0003JY-00@usw-sf-web1.sourceforge.net>

Bugs item #426735, was updated on 2001-05-23 12:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426735&group_id=5470

>Category: Python Interpreter Core
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
>Summary: [Linux] Threaded Python program hangs

Initial Comment:
import thread, os, time
thread.start_new_thread(os._exit, (1,))
time.sleep(1)
print "done"

The program never prints "done".

Python 2.1 (tummy RPM 2.1-4)
RedHat 6.2

strace of the main thread shows:
select(0, NULL, NULL, NULL, {1, 0})     = 0 (Timeout)
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
rt_sigsuspend([]
... Python completes the time.sleep() call, and then
hangs waiting something.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-28 18:47

Message:
Logged In: YES 
user_id=31435

Changed to platform-specific, since it Works For Me on 
Win98SE.  However, I'm not sure what "works" means:  what 
do the Linux docs say _exit should do when called from a 
spawned thread?  Does this program fail the same way if you 
write it in C?  It may have to do with that Python 
implements time.sleep() on Linux via select(), to get fine
(r)-grained resolution.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426735&group_id=5470


From noreply@sourceforge.net  Tue May 29 02:52:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 28 May 2001 18:52:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-426735 ] [Linux] Threaded Python program hangs
Message-ID: <E154YgF-0003Mu-00@usw-sf-web1.sourceforge.net>

Bugs item #426735, was updated on 2001-05-23 12:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426735&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: [Linux] Threaded Python program hangs

Initial Comment:
import thread, os, time
thread.start_new_thread(os._exit, (1,))
time.sleep(1)
print "done"

The program never prints "done".

Python 2.1 (tummy RPM 2.1-4)
RedHat 6.2

strace of the main thread shows:
select(0, NULL, NULL, NULL, {1, 0})     = 0 (Timeout)
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
rt_sigsuspend([]
... Python completes the time.sleep() call, and then
hangs waiting something.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-28 18:52

Message:
Logged In: YES 
user_id=31435

BTW, it doesn't print "done" for me on Win98 either, and I 
didn't expect it to:  _exit() is a "panic! stop the world!" 
function.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-28 18:47

Message:
Logged In: YES 
user_id=31435

Changed to platform-specific, since it Works For Me on 
Win98SE.  However, I'm not sure what "works" means:  what 
do the Linux docs say _exit should do when called from a 
spawned thread?  Does this program fail the same way if you 
write it in C?  It may have to do with that Python 
implements time.sleep() on Linux via select(), to get fine
(r)-grained resolution.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426735&group_id=5470


From noreply@sourceforge.net  Tue May 29 08:30:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 00:30:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-231207 ] Fatal Python Error during program shutdown
Message-ID: <E154dx7-0007dn-00@usw-sf-web1.sourceforge.net>

Bugs item #231207, was updated on 2001-02-05 18:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Henderson (djhender)
Assigned to: Fredrik Lundh (effbot)
Summary: Fatal Python Error during program shutdown

Initial Comment:
The windows builds of versions 2.0 and 2.1a2 contain an intermittent bug which often appears when a script using Tkinter stops by calling self.tk.quit() and sometimes (less often) appears following a <Destroy> event or call to a ?.destory() function.
Under Windows 98SE, this results in a GPF.
Under Windows 2000, a message to the console window shows "Fatal Python Error", "PyEval_RestoreThread NULL tstate".

The following script demonstrates the problem:
---------------------
# BugDemo.py

from Tkinter import *

class BugDemo(Frame):
    def __init__(self, parent):
        Frame.__init__(self, parent)
        Button(self, text='Hi', command=self.hi).pack()
        Button(self, text='Quit', command=self.tk.quit).pack()
    def hi(self):
        print "hi"

bd = BugDemo(Tk())
bd.pack()
bd.mainloop()
----------------------
Execute in console window: "c:> python BugDemo.py"
Test this by 1) clicking Quit button 2) clicking Hi button, then Quit button.
Test 1: The script runs successfully most of the time. I found I had to minimize and restore its window to make it fail regularly.
Test 2: I need to click Hi button before clicking the Quit button. Then it failed about half the time.

The problem appears to occur after the script has completed, during some kind of cleanup perhaps. The more useful error message on the Win2k machine may help to locate the problem.

Problem also manifests using the PythonWare 2.0 release on Win98.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 00:30

Message:
Logged In: NO 

Note:
I am running Windows98
ActivePython 2.1
Even with console apps in python this same error appears
I tried using another Distribution of Python for win32, 
PythonWare20

So this leads me to believe that some lib is missing on 
win98. Because at work I use Win95, and Installed 
ActivePython 2.1, and it works fine and dandy


----------------------------------------------------------------------

Comment By: Joel Gould (joelgould)
Date: 2001-03-24 08:52

Message:
Logged In: YES 
user_id=20954

I also see a GPF on shutdown under Windows 98 using 
Tkinter.  I tested this using the PythonWare 2.0 release as 
well.

I have attached a very simple Tkinter program.  When I run 
this on my Windows 98 SE machine, a crash occurs when the 
program exits.  Without the MainDialog class it works OK.  
Without the Pmw initialization call it works OK.  But as 
written it will crash around 75% of the time.

(1) run the program
(2) press the Test Button
(3) click Cancel in the file open dialog (you do not need 
to select a file)
(4) click the close button in the upper right corner
-->  Boom

--------------------

import Tkinter
import tkFileDialog
import Pmw

def action():
    tkFileDialog.askopenfilename(filetypes=[('All','*')])

class MainDialog:
    def __init__(self,parent):
        Tkinter.Button(parent,text='Test 
Button',command=action).pack()

root = Pmw.initialise()
dialog = MainDialog(root)
root.mainloop()

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-09 15:34

Message:
Assigned to /F, under the theory he can confirm that "this kind of thing" is still a general problem with Tk we can't do anything about.

----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2001-02-05 21:30

Message:
See also #116289 (and my comment to it) which describes what often happened to my 'real' programs which lead to developing the above BugDemo script. My 'real' programs were developed over the last two years or so, and worked in Jan 2000 with 1.5.2. I upgraded the Python version recently, and then started working on these programs again. It was "WTF is wrong with my code", until I found the same problem showing up in the small test cases.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470


From noreply@sourceforge.net  Tue May 29 13:55:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 05:55:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-428289 ] Integrates log4p
Message-ID: <E154j1y-0003Yf-00@usw-sf-web3.sourceforge.net>

Bugs item #428289, was updated on 2001-05-29 05:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428289&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: eXom (jkuan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Integrates log4p

Initial Comment:
I have read about log4j which is great for developers.
Also notice that has been ported to python, log4p,
log4p.sourceforge.net. I personally think this will be
one of the great tools if it integrates into python
core. At least more open source python developer will
definitely want to use it, rather than they have to
maintain their own log4p. Now python has a module that
provides auto test framework, I deeply think the next
thing should be logging.


Thanks
Joe

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428289&group_id=5470


From noreply@sourceforge.net  Tue May 29 16:39:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 08:39:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-427985 ] optional "listen" parameter in asyncore
Message-ID: <E154las-0000AQ-00@usw-sf-web2.sourceforge.net>

Bugs item #427985, was updated on 2001-05-28 09:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427985&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: optional "listen" parameter in asyncore

Initial Comment:
Python Docs.

Library Reference for Python 2.1

Asyncore module, pag 312.

"Listen" parameter "backlog" is 'typesetted' like an
optional parameter, but the parameter is not optional.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-29 08:39

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libasyncore.tex revisions 1.8 and 1.7.2.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427985&group_id=5470


From noreply@sourceforge.net  Tue May 29 16:45:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 08:45:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-427783 ] Lang Ref  section 4.1 s/is/in/
Message-ID: <E154lgu-0000Fr-00@usw-sf-web2.sourceforge.net>

Bugs item #427783, was updated on 2001-05-27 15:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427783&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Lang Ref  section 4.1 s/is/in/

Initial Comment:
The built-in namespace associated with the execution of
a code block is actually found by looking up the name
__builtins__ is its global namespace; 

I am pretty sure what's intended is
s/is its/in its/

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-29 08:45

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/ref/ref4.tex revisions 1.27 and 1.26.2.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427783&group_id=5470


From noreply@sourceforge.net  Tue May 29 16:48:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 08:48:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-423779 ] sgmllib.py not good at handling <br/>
Message-ID: <E154lj5-0000I7-00@usw-sf-web2.sourceforge.net>

Bugs item #423779, was updated on 2001-05-13 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423779&group_id=5470

Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sgmllib.py not good at handling <br/>

Initial Comment:
When parsing the following HTML:

'Roses <b>are</B> red,<br/>violets <i>are</i> blue'

...with the following class:

class HTML2SafeHTML(sgmllib.SGMLParser):
    
    def handle_data(self, data):
        print "***data***"
        print data

    def unknown_starttag(self, tag, attrs):
        print "***start**"
        print tag
        pprint (attrs)
        pprint (self.openTags)
                
    def unknown_endtag(self, tag):
        print "***end**"
        print tag
        pprint (self.openTags)

I get the following output, which isn't right :-S

***data***
Roses
***start**
b
[]
[]
***data***
are
***end**
b
['b']
***data***
 red,
***start**
br
[]
[]
***data***
>violets <i>are<
***end**
br
[]
***data***
i> blue

cheers,

Chris

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-29 08:48

Message:
Logged In: YES 
user_id=3066

Closing this as Not-A-Bug since no one is contesting my comments and an alternate approach, arguably better, has been identified.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2001-05-17 14:49

Message:
Logged In: YES 
user_id=24723

Hmmm, from comments on the Python list, I understood XML to 
be a subset of SGML, implying that sgmlib should at least 
do something sensible with the stuff above ;-)

That said, I'm not too fussed about this anymore as 
TAL.HTMLParser solved all of my problems.
Is this the right place to beg for it to be included in the 
standard python distribution?

Thanks for your help,

Chris

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-16 08:54

Message:
Logged In: YES 
user_id=3066

While there is definately space for improvement in sgmllib, and probably a need for a few bug fixes, it is not clear that this is one of the bugs.

SGML defines something called the "null end tag" (NET) and the "NET enabler".  In a document, this looks like:

    <tag/ content /

This represents an element "tag" with the content " content ".  The first slash is the enabler and the second is the NET.  Basic support for this has been a part of sgmllib for as long as I can remember; it was added before I started playing with it.

In practice, use of the NET in HTML doesn't seem to exist.  Perhaps it should be something that can be specifically enabled or disabled?  I'm more inclined to say that sgmllib should not be used for XHTML though -- XHTML is *not* SGML, it's XML, and that's something different.

Have you tried to apply xmllib to your application?  Given your desire (stated elsewhere) to work with seriously broken HTML as well, you may be better off using a custom parser similar to TAL.HTMLParser used by PageTemplates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423779&group_id=5470


From noreply@sourceforge.net  Tue May 29 17:01:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 09:01:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-428342 ] [IRIX] crash on int->float conversio
Message-ID: <E154lw9-0006GD-00@usw-sf-web3.sourceforge.net>

Bugs item #428342, was updated on 2001-05-29 09:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428342&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles Schwieters (chuckorama)
Assigned to: Nobody/Anonymous (nobody)
Summary: [IRIX] crash on int->float conversio

Initial Comment:
here is a snippet from a python session running on
IRIX 6.5.11m, compiled with the native compiler

% python
Python 2.1 (#3, May 29 2001, 10:15:29) [C] on irix646
>>> amin = 0; a=1.0; Na=10
>>> xmin = amin * a / Na
Bus error (core dumped)

I also had this problem with version 2.1b2. 

It works fine if I explicitly change the integers to
floats

it runs fine on Linux and Solaris platforms.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428342&group_id=5470


From noreply@sourceforge.net  Tue May 29 17:06:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 09:06:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-427698 ] objects with __eq__ are not hashable
Message-ID: <E154m12-0006JO-00@usw-sf-web1.sourceforge.net>

Bugs item #427698, was updated on 2001-05-27 05:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427698&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: objects with __eq__ are not hashable

Initial Comment:
The following code fails with Python2.1, on both SGI
IRIX 6.5 and Linux (Suse7.1)

class A:
    _name = 'AA'
    def __init__(self,name):
        self._name = name
    def __eq__(self,a):
        if (a._name == self._name):
            return 1
        else:
            return 0
    def __str__(self):
        return self._name

a = A('abc')

c = {}

c[a] = 1


===> 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unhashable instance

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-29 09:06

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/ref/ref3.tex revisions 1.67 and 1.64.2.2.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-27 14:26

Message:
Logged In: YES 
user_id=31435

If a class defines __eq__ or __cmp__, then for instances to 
be hashable it must also define __hash__.

Changed Category to Documentation and assigned to Fred.  
Ref Man Section 3.3.1 (Basic customization) explains this 
about __hash__, but only mentions __cmp__.  Guido should 
have changed this to include __eq__ too (i.e., everywhere 
__hash__ mentions __cmp__() now it should add "or __eq__
()").

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427698&group_id=5470


From noreply@sourceforge.net  Tue May 29 17:29:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 09:29:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E154mNP-0006e7-00@usw-sf-web3.sourceforge.net>

Bugs item #427345, was updated on 2001-05-25 10:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer fix for Windows

Initial Comment:
CGIHTTPServer.py in the Python 2.1 library needs two 
changes to the popen2 section in order to support 
binary data and to avoid buffering problems under 
Windows. The complete code block is shown at the end 
of this message. The two changed lines are:
cmdline = "%s -u %s" % (interp, cmdline)
fi, fo = os.popen2(cmdline, 'b')

I've tested this under Windows 2000 Pro and binary 
file uploads now work, however more extensive tests 
should probably be done.

It appears there is another socket-related problem 
and/or end-of-line conversion error that occurs when 
using Internet Explorer 5.x and BASEHTTPServer with 
CGIHTTPServer on the same machine. I'm still 
investigating that issue.

Finally, I have done a small rewrite of 
CGIHTTPServer.py to simplify subclassing it to support 
running CGIs in any or all directories and using other 
file extensions such as .cgi. The maintainer for the 
current file should email me about the changes to see 
whether they want to update the official library file. 
I didn't post it here since it needs more tweaking

ka
---
CGIHTTPServer.p fixes...
elif self.have_popen2:
    # Windows -- use popen2 to create a subprocess
    import shutil
    os.environ.update(env)
    cmdline = scriptfile
    if self.is_python(scriptfile):
        interp = sys.executable
        if interp.lower().endswith("w.exe"):
            # On Windows, use python.exe, not 
python.exe
            interp = interp[:-5] = interp[-4:]
        cmdline = "%s -u %s" % (interp, cmdline)
    if '=' not in query and '"' not in query:
        cmdline = '%s "%s"' % (cmdline, query)
    self.log_error("command: %s", cmdline)
    try:
        nbytes = int(length)
    except:
        nbytes = 0
    fi, fo = os.popen2(cmdline, 'b')
    if self.command.lower() == "post" and nbytes > 0:
        data = self.rfile.read(nbytes)
        fi.write(data)
    fi.close()
    shutil.copyfileobj(fo, self.wfile)
    sts = fo.close()
    if sts:
        self.log_error("CGI script exit status %#x", 
sts)
    else:
        self.log_error("CGI script exited OK")


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 09:29

Message:
Logged In: NO 

I want to elaborate on the second-to-last 
paragraph in this report.  CGIHTTPServer 
in 2.1 and 2.0 is apparently broken for 
POST requests (only) to CGI scripts, when
running locally on Windows with an IE client.

The details: there is a problem with 
the combination of a CGIHTTPServer and 
Intenernet Explorer both running locally 
on Windows (with server name "localhost").
In this setup, POST requests to CGI scripts
fail, but GET requests to the exact same 
script work fine.  That is, a form with 
method=GET, or a URL with an appended 
query string, both work ok.

In POST mode, the CGI script gets proper
data in the input stream, and generates 
a correct reply stream (which is in fact 
identical to the output generated for 
quivalent GET requests).  So, somewhere 
between CGIHTTPServer and IE, the data 
seems to be dropped or munged.  The same
thing happens of you force CGIHTTPServer 
to use execfile() to launch the script, 
instead of os.popen2.

I've also observed that endline conventions 
seem to be irrelevant to the problem; using 
\n or \r\n makes no difference in both the 
input and reply streams.  I've also been 
told that the problem may not exist in 
Netscape clients.

Since CGIHTTPServer is a very nice way to test
CGI scripts (all you need is a standard Python
install), this seems important.  It would also 
be nice if the directory assumptions in that 
module were more customizable, but that's just
a wish.

--Mark Lutz


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470


From noreply@sourceforge.net  Tue May 29 19:29:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 11:29:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-428391 ] Error in PySequence_Fast_GET_ITEM doc
Message-ID: <E154oFJ-0008MV-00@usw-sf-web3.sourceforge.net>

Bugs item #428391, was updated on 2001-05-29 11:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428391&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Yakov Markovitch (markovitch)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Error in PySequence_Fast_GET_ITEM doc

Initial Comment:
>From the PySequence_Fast_GET_ITEM description:
"The caller is expected to get the length of the
sequence by calling PyObject_Size() on o, since lists
and tuples are guaranteed to always return their true
length."

There should obviously be PySequence_Size() instead of
PyObject_Size().

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428391&group_id=5470


From noreply@sourceforge.net  Tue May 29 19:53:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 11:53:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-428391 ] Error in PySequence_Fast_GET_ITEM doc
Message-ID: <E154ocb-0000LW-00@usw-sf-web1.sourceforge.net>

Bugs item #428391, was updated on 2001-05-29 11:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428391&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Yakov Markovitch (markovitch)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Error in PySequence_Fast_GET_ITEM doc

Initial Comment:
>From the PySequence_Fast_GET_ITEM description:
"The caller is expected to get the length of the
sequence by calling PyObject_Size() on o, since lists
and tuples are guaranteed to always return their true
length."

There should obviously be PySequence_Size() instead of
PyObject_Size().

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-29 11:53

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/api/api.tex revisions 1.125 and 1.117.2.3.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428391&group_id=5470


From noreply@sourceforge.net  Tue May 29 20:53:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 12:53:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-428419 ] include/rangeobject.h needs extern "C"
Message-ID: <E154pYj-0001GS-00@usw-sf-web1.sourceforge.net>

Bugs item #428419, was updated on 2001-05-29 12:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428419&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Alan Scott (barry-scott)
Assigned to: Nobody/Anonymous (nobody)
Summary: include/rangeobject.h needs extern "C"

Initial Comment:
include/rangeobject.h needs extern "C" if compiling
for C++ as the other .h files have.

The workaround is to add these lines to the my app 
code:

extern "C" DL_IMPORT(PyTypeObject) PyRange_Type;
extern "C" DL_IMPORT(PyObject *) PyRange_New(long, 
long, long, int);



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428419&group_id=5470


From noreply@sourceforge.net  Tue May 29 21:16:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 13:16:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-426735 ] [Linux] Threaded Python program hangs
Message-ID: <E154pv5-0001bI-00@usw-sf-web1.sourceforge.net>

Bugs item #426735, was updated on 2001-05-23 12:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426735&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: [Linux] Threaded Python program hangs

Initial Comment:
import thread, os, time
thread.start_new_thread(os._exit, (1,))
time.sleep(1)
print "done"

The program never prints "done".

Python 2.1 (tummy RPM 2.1-4)
RedHat 6.2

strace of the main thread shows:
select(0, NULL, NULL, NULL, {1, 0})     = 0 (Timeout)
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
rt_sigsuspend([]
... Python completes the time.sleep() call, and then
hangs waiting something.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-29 13:16

Message:
Logged In: YES 
user_id=31435

Use thread.exit() to abort a thread.

os._exit() is platform-dependent.  On Linux it exits only 
the thread that invokes it, and if that thread holds the 
global interpreter lock at the time, all other threads will 
hang.  On Windows it kills off the process, and all threads 
ever spawned by the process.  I suspect other Unices behave 
more like Windows than Linux here, but clear docs are hard 
to find.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-28 18:52

Message:
Logged In: YES 
user_id=31435

BTW, it doesn't print "done" for me on Win98 either, and I 
didn't expect it to:  _exit() is a "panic! stop the world!" 
function.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-28 18:47

Message:
Logged In: YES 
user_id=31435

Changed to platform-specific, since it Works For Me on 
Win98SE.  However, I'm not sure what "works" means:  what 
do the Linux docs say _exit should do when called from a 
spawned thread?  Does this program fail the same way if you 
write it in C?  It may have to do with that Python 
implements time.sleep() on Linux via select(), to get fine
(r)-grained resolution.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426735&group_id=5470


From noreply@sourceforge.net  Tue May 29 22:46:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 14:46:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-427524 ] path formatter between unix and windows
Message-ID: <E154rK7-0004Q7-00@usw-sf-web2.sourceforge.net>

Bugs item #427524, was updated on 2001-05-26 03:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427524&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: eXom (jkuan)
>Assigned to: Paul Prescod (prescod)
Summary: path formatter between unix and windows

Initial Comment:
Is it possible to have a function that converts the
unix path format into windows format, vice versa?

Or is there any function that does that already?

e.g.

def unix2winPath(pathName, drive='C:')
raise exception if there is any invalid character in
pathName


Thanks
Joe

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427524&group_id=5470


From noreply@sourceforge.net  Tue May 29 22:47:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 14:47:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-427060 ] pydoc: inconsistent behavior for imports
Message-ID: <E154rKW-0004QS-00@usw-sf-web2.sourceforge.net>

Bugs item #427060, was updated on 2001-05-24 13:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427060&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bryan Nollett (nollett)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc: inconsistent behavior for imports

Initial Comment:
Consider a module mymod.py containing the following two
import statements:

from md5 import new
from base64 import decode

Running "pydoc mymod" yields a helpfile containing a
description of function new from md5 but not function
decode from base64.  The distinction seems to be that
new is a built-in function while decode is a "plain"
function.  From a user's perspective however, this
seems to be very inconsistent.

>From a very brief glance at pydoc.py, this distinction
appears to be an intentional one, but it is not clear
to me why this behavior would be desirable, at least in
this (very typical?) example.

As a further example, consider mymod.py containing a
different import statement:

from Numeric import array, arange, resize, zeros

Some functions in Numeric are built-ins and others
"plain" functions. So here "pydoc mymod" would include
documentation for array and zeros (since they happen to
be implemented as built-ins) and not arange or resize.

I think pydoc follows a rule something like this:

imported classes -- not documented
imported functions -- documented only if built-in
imported "data" -- documented (with obvious exceptions)

Perhaps the default behavior should be that *none* of
the imported symbols be documented?  (If all are
documented, this makes pydoc much less usable with
Numeric or Tkinter where the "from Tkinter import *"
idiom is often a necessary evil.)  I can see cases
where one would like imported symbols to be documented
but do not see a mechanism currently in place to
distinguish between the two uses.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427060&group_id=5470


From noreply@sourceforge.net  Tue May 29 22:47:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 14:47:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-426892 ] grid_location class at the wrong place
Message-ID: <E154rKt-0004Qq-00@usw-sf-web2.sourceforge.net>

Bugs item #426892, was updated on 2001-05-24 01:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426892&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fredrik Lundh (effbot)
Summary: grid_location class at the wrong place

Initial Comment:
grid_location is a method for the master, and thus it
should be in Misc instead of Grid.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426892&group_id=5470


From noreply@sourceforge.net  Tue May 29 22:48:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 14:48:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E154rM4-0004Rp-00@usw-sf-web2.sourceforge.net>

Bugs item #427345, was updated on 2001-05-25 10:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: CGIHTTPServer fix for Windows

Initial Comment:
CGIHTTPServer.py in the Python 2.1 library needs two 
changes to the popen2 section in order to support 
binary data and to avoid buffering problems under 
Windows. The complete code block is shown at the end 
of this message. The two changed lines are:
cmdline = "%s -u %s" % (interp, cmdline)
fi, fo = os.popen2(cmdline, 'b')

I've tested this under Windows 2000 Pro and binary 
file uploads now work, however more extensive tests 
should probably be done.

It appears there is another socket-related problem 
and/or end-of-line conversion error that occurs when 
using Internet Explorer 5.x and BASEHTTPServer with 
CGIHTTPServer on the same machine. I'm still 
investigating that issue.

Finally, I have done a small rewrite of 
CGIHTTPServer.py to simplify subclassing it to support 
running CGIs in any or all directories and using other 
file extensions such as .cgi. The maintainer for the 
current file should email me about the changes to see 
whether they want to update the official library file. 
I didn't post it here since it needs more tweaking

ka
---
CGIHTTPServer.p fixes...
elif self.have_popen2:
    # Windows -- use popen2 to create a subprocess
    import shutil
    os.environ.update(env)
    cmdline = scriptfile
    if self.is_python(scriptfile):
        interp = sys.executable
        if interp.lower().endswith("w.exe"):
            # On Windows, use python.exe, not 
python.exe
            interp = interp[:-5] = interp[-4:]
        cmdline = "%s -u %s" % (interp, cmdline)
    if '=' not in query and '"' not in query:
        cmdline = '%s "%s"' % (cmdline, query)
    self.log_error("command: %s", cmdline)
    try:
        nbytes = int(length)
    except:
        nbytes = 0
    fi, fo = os.popen2(cmdline, 'b')
    if self.command.lower() == "post" and nbytes > 0:
        data = self.rfile.read(nbytes)
        fi.write(data)
    fi.close()
    shutil.copyfileobj(fo, self.wfile)
    sts = fo.close()
    if sts:
        self.log_error("CGI script exit status %#x", 
sts)
    else:
        self.log_error("CGI script exited OK")


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 09:29

Message:
Logged In: NO 

I want to elaborate on the second-to-last 
paragraph in this report.  CGIHTTPServer 
in 2.1 and 2.0 is apparently broken for 
POST requests (only) to CGI scripts, when
running locally on Windows with an IE client.

The details: there is a problem with 
the combination of a CGIHTTPServer and 
Intenernet Explorer both running locally 
on Windows (with server name "localhost").
In this setup, POST requests to CGI scripts
fail, but GET requests to the exact same 
script work fine.  That is, a form with 
method=GET, or a URL with an appended 
query string, both work ok.

In POST mode, the CGI script gets proper
data in the input stream, and generates 
a correct reply stream (which is in fact 
identical to the output generated for 
quivalent GET requests).  So, somewhere 
between CGIHTTPServer and IE, the data 
seems to be dropped or munged.  The same
thing happens of you force CGIHTTPServer 
to use execfile() to launch the script, 
instead of os.popen2.

I've also observed that endline conventions 
seem to be irrelevant to the problem; using 
\n or \r\n makes no difference in both the 
input and reply streams.  I've also been 
told that the problem may not exist in 
Netscape clients.

Since CGIHTTPServer is a very nice way to test
CGI scripts (all you need is a standard Python
install), this seems important.  It would also 
be nice if the directory assumptions in that 
module were more customizable, but that's just
a wish.

--Mark Lutz


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470


From noreply@sourceforge.net  Tue May 29 22:49:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 14:49:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-426539 ] Math-module lacks some docs and funcs
Message-ID: <E154rMR-0004SA-00@usw-sf-web2.sourceforge.net>

Bugs item #426539, was updated on 2001-05-22 21:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426539&group_id=5470

Category: Extension Modules
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Rikard Bosnjakovic (bosna)
>Assigned to: Tim Peters (tim_one)
Summary: Math-module lacks some docs and funcs

Initial Comment:
>>> import math
>>> print math.cos.__doc__
cos(x)

Return the cosine of x.


1. That doc-string is not very sufficient, since it
does not tell whether x should be in radians or
degrees. Same goes with sin, asin, acos and the rest of
the degree-functions.

2. ceil() and floor() could have some more information
of what the functions does. Not all users have taken
math-courses and know about them.

3. Add a degrees(x) and radians(x) that converts "x" to
degrees (from a radian argument) and to radians (from a
degree argument) respectively, it's pretty useful.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426539&group_id=5470


From noreply@sourceforge.net  Tue May 29 22:55:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 14:55:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-426960 ] fork problem with Python-2.1
Message-ID: <E154rS9-0004W9-00@usw-sf-web2.sourceforge.net>

Bugs item #426960, was updated on 2001-05-24 09:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426960&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Steinhoff (arminsteinhoff)
Assigned to: Nobody/Anonymous (nobody)
Summary: fork problem with Python-2.1

Initial Comment:

I have a strange problem with Python2.1 running QNX6.
The test script test_fork1.py returns with following result:

# python -t test_fork1.py
/* sys.path include in script ... */
['', '/usr/local/lib/python2.1', '/usr/local/lib/python2.1/Lib/lib-tk',
'/usr/local/lib/python2.1/lib/python2.1', '/usr/local/
lib/python2.1/lib/python2.1/plat-qnx6',
'/usr/local/lib/python2.1/lib/python2.1/lib-tk',
'/usr/local/lib/python2.1/lib/python2 .1/lib-dynload']
Traceback (most recent call last):
  File "test_fork1.py", line 76, in ?
    main()
  File "test_fork1.py", line 55, in main
    cpid = os.fork()
OSError: [Errno 89] Function not implemented

----------------------------------------------------------------------
That's very strange ... because it works in the interactive mode =:-(
----------------------------------------------------------------------

# python
Python 2.1 (#16, May 11 2001, 18:37:57)
[GCC 2.95.2 19991024 (release)] on qnx6
Type "copyright", "credits" or "license" for more information.
>>> import sys, os
>>>sys.path
['', '/usr/local/lib/python2.1', '/usr/local/lib/python2.1/Lib/lib-tk',
'/usr/local/lib/python2.1/lib/python2.1',
'/usr/local/lib/python2.1/lib/python2.1/plat-qnx6',
'/usr/local/lib/python2.1/lib/python2.1/lib-tk',
'/usr/local/lib/python2.1/lib/python2 .1/lib-dynload']
>>>
>>> os.fork
<built-in function fork>
>>> os.fork()
6512990

Any ideas where to look?

Armin



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-29 14:55

Message:
Logged In: YES 
user_id=31392

test_fork1 tests the behavior of threads across a fork (why
this is important is not entirely clear to me).  Perhaps the
problem you see is that fork() behaves differently in the
presence of threads.

Did you try this?
>>> import test.test_fork1

Is os.name == "posix" on your system?  Or does fork() come
from somewhere other than the posix module?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426960&group_id=5470


From noreply@sourceforge.net  Tue May 29 22:55:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 14:55:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-424680 ] distutils module version # not StrictVer
Message-ID: <E154rSU-0004WY-00@usw-sf-web2.sourceforge.net>

Bugs item #424680, was updated on 2001-05-16 15:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424680&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: A.M. Kuchling (akuchling)
Summary: distutils module version # not StrictVer

Initial Comment:
There is a fairly detailed definition in the distutils 
module (in version.py) about valid (or Strict) version 
numbers.  However the version number of the distutils 
module does not conform to this numbering scheme.  
Specifically 

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import distutils
>>> distutils.__version__
'1.0.2pre'
>>> from distutils.version import StrictVersion
>>> StrictVersion(distutils.__version__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\program files\python21
\lib\distutils\version.py", line 42, in __init__
    self.parse(vstring)
  File "c:\program files\python21
\lib\distutils\version.py", line 109, in parse
    raise ValueError, "invalid version number '%s'" % 
vstring
ValueError: invalid version number '1.0.2pre'
>>>




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424680&group_id=5470


From noreply@sourceforge.net  Tue May 29 22:57:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 14:57:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-423472 ] Hang in select.select() and time.sleep()
Message-ID: <E154rUC-0004Xu-00@usw-sf-web2.sourceforge.net>

Bugs item #423472, was updated on 2001-05-11 17:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423472&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Seguin (rpseguin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hang in select.select() and time.sleep()

Initial Comment:
Platform:  FreeBSD 4.0
Python version:   2.0 and 2.1  (maybe 1.5.2, haven't
tried)

There is a bug in the select() code that manifests
itself as a hang of the process if the system clock is
adjusted during a call to  select.select() or
time.sleep()  (which uses select())

I'm guessing that this might be related to the
reentrant., thread-safe libc_r.so used by the Python
runtime.


Steps to reproduce:

rseguin% python
Python 2.1 (#1, May 11 2001, 16:54:06)
[GCC 2.95 19990728 (release)] on freebsd4
Type "copyright", "credits" or "license" for more
information.
>>> import time
>>>
time.sleep(10.0)                                                            
(now set the system clock date/time via another shell)

Result is one of two things:
-ether  time.sleep()  (or select.select()) never comes
back
-OR it comes back after the time delta from previous
time before clock adjust and the adjusted time + the
desired sleep time interval.

This bug is more insidious than it may initially seem,
as there are any of a number of time adjusting daemons
(xntpd, ntpd, ...).  This is a nasty bug for daemon
style code in particular, as the daemon appears to be
running, while it is actually just hung.

This bug was in 2.0 and it is still there in 2.1

-Ralph
rpseguin@yahoo.com




----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-29 14:57

Message:
Logged In: YES 
user_id=31392

What happens to a C program if you do the same?  I can't
tell if this is a Python bug or a C library bug, if indeed
it is a bug.  I'm not sure what these functions are supposed
to do when the clock is adjusted.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423472&group_id=5470


From noreply@sourceforge.net  Tue May 29 23:08:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 15:08:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-427524 ] path formatter between unix and windows
Message-ID: <E154rev-0003DB-00@usw-sf-web1.sourceforge.net>

Bugs item #427524, was updated on 2001-05-26 03:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427524&group_id=5470

Category: Extension Modules
Group: Feature Request
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: eXom (jkuan)
Assigned to: Paul Prescod (prescod)
Summary: path formatter between unix and windows

Initial Comment:
Is it possible to have a function that converts the
unix path format into windows format, vice versa?

Or is there any function that does that already?

e.g.

def unix2winPath(pathName, drive='C:')
raise exception if there is any invalid character in
pathName


Thanks
Joe

----------------------------------------------------------------------

>Comment By: Paul Prescod (prescod)
Date: 2001-05-29 15:08

Message:
Logged In: YES 
user_id=31788

This idea is problematic. First, why would you want it? How 
would a Unix path get onto Windows and vice versa? Given a 
Unix path got onto Windows, why would you expect it to be 
useful? i.e. what's the Windows equivalent 
to /usr/sbin/foo ?

If all you want to do is reverse the slashes and append a 
drive letter, I would suggest:
def unix2winpath(pathname, drive="c:"):
    os.path.normpath(drive+pathname)

This will translate slashes into backslashes appropriately.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427524&group_id=5470


From noreply@sourceforge.net  Wed May 30 05:24:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 21:24:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-428342 ] [IRIX] crash on int->float conversio
Message-ID: <E154xX8-0008DT-00@usw-sf-web2.sourceforge.net>

Bugs item #428342, was updated on 2001-05-29 09:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428342&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles Schwieters (chuckorama)
Assigned to: Nobody/Anonymous (nobody)
Summary: [IRIX] crash on int->float conversio

Initial Comment:
here is a snippet from a python session running on
IRIX 6.5.11m, compiled with the native compiler

% python
Python 2.1 (#3, May 29 2001, 10:15:29) [C] on irix646
>>> amin = 0; a=1.0; Na=10
>>> xmin = amin * a / Na
Bus error (core dumped)

I also had this problem with version 2.1b2. 

It works fine if I explicitly change the integers to
floats

it runs fine on Linux and Solaris platforms.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-29 21:24

Message:
Logged In: YES 
user_id=31435

First thing to try with any problem on IRIX is to recompile 
Python with optimization turned off.  That's usually all 
there is to it.  Then, if that fixes it and you feel like 
it, you can play binary search to determine which file 
optimization is breaking (floatobject.c would be my first 
guess).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428342&group_id=5470


From noreply@sourceforge.net  Wed May 30 07:07:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 29 May 2001 23:07:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-428555 ] IDLE crashes
Message-ID: <E154z98-0000lr-00@usw-sf-web1.sourceforge.net>

Bugs item #428555, was updated on 2001-05-29 23:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428555&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE crashes 

Initial Comment:
On Windows 2000 (havent tested other platforms) IDLE 
will crash if i run the following code (ditto for 
PythonWin)

from Tkinter import *

root = Tk()
img = PhotoImage(root,file="somefile.gif")
# the error here is that i used root as the name





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428555&group_id=5470


From noreply@sourceforge.net  Wed May 30 09:06:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 01:06:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-426960 ] fork problem with Python-2.1
Message-ID: <E1550zj-0002H7-00@usw-sf-web1.sourceforge.net>

Bugs item #426960, was updated on 2001-05-24 09:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426960&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Steinhoff (arminsteinhoff)
Assigned to: Nobody/Anonymous (nobody)
Summary: fork problem with Python-2.1

Initial Comment:

I have a strange problem with Python2.1 running QNX6.
The test script test_fork1.py returns with following result:

# python -t test_fork1.py
/* sys.path include in script ... */
['', '/usr/local/lib/python2.1', '/usr/local/lib/python2.1/Lib/lib-tk',
'/usr/local/lib/python2.1/lib/python2.1', '/usr/local/
lib/python2.1/lib/python2.1/plat-qnx6',
'/usr/local/lib/python2.1/lib/python2.1/lib-tk',
'/usr/local/lib/python2.1/lib/python2 .1/lib-dynload']
Traceback (most recent call last):
  File "test_fork1.py", line 76, in ?
    main()
  File "test_fork1.py", line 55, in main
    cpid = os.fork()
OSError: [Errno 89] Function not implemented

----------------------------------------------------------------------
That's very strange ... because it works in the interactive mode =:-(
----------------------------------------------------------------------

# python
Python 2.1 (#16, May 11 2001, 18:37:57)
[GCC 2.95.2 19991024 (release)] on qnx6
Type "copyright", "credits" or "license" for more information.
>>> import sys, os
>>>sys.path
['', '/usr/local/lib/python2.1', '/usr/local/lib/python2.1/Lib/lib-tk',
'/usr/local/lib/python2.1/lib/python2.1',
'/usr/local/lib/python2.1/lib/python2.1/plat-qnx6',
'/usr/local/lib/python2.1/lib/python2.1/lib-tk',
'/usr/local/lib/python2.1/lib/python2 .1/lib-dynload']
>>>
>>> os.fork
<built-in function fork>
>>> os.fork()
6512990

Any ideas where to look?

Armin



----------------------------------------------------------------------

Comment By: Armin Steinhoff (arminsteinhoff)
Date: 2001-05-30 01:06

Message:
Logged In: YES 
user_id=64602


Hello Jeremy,

here are the reponses to os.name and import test.test_fork1:

# python
Python 2.1 (#16, May 11 2001, 18:37:57)
[GCC 2.95.2 19991024 (release)] on qnx6
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> os.name
'posix'
>>> import test.test_fork1
['', '/root/Python-2.1/Lib', '/root/Python-2.1/Lib/Lib/lib-tk', '/root/Python-2.1/Lib/lib/python2.1', 
'/root/Python-2.1/Lib/lib/python2.1/plat-qnx6', '/root/Python-2.1/Lib/lib/python2.1/lib-tk', 
'/root/Python-2.1/Lib/lib/python2.1/lib-dynload']
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/root/Python-2.1/Lib/test/test_fork1.py", line 76, in ?
main()
File "/root/Python-2.1/Lib/test/test_fork1.py", line 55, in main
cpid = os.fork()
OSError: [Errno 89] Function not implemented
>>>

But 'fork' is of course implemented ...

Armin


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-29 14:55

Message:
Logged In: YES 
user_id=31392

test_fork1 tests the behavior of threads across a fork (why
this is important is not entirely clear to me).  Perhaps the
problem you see is that fork() behaves differently in the
presence of threads.

Did you try this?
>>> import test.test_fork1

Is os.name == "posix" on your system?  Or does fork() come
from somewhere other than the posix module?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426960&group_id=5470


From noreply@sourceforge.net  Wed May 30 14:07:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 06:07:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-428342 ] [IRIX] crash on int->float conversio
Message-ID: <E1555hU-0006Bn-00@usw-sf-web1.sourceforge.net>

Bugs item #428342, was updated on 2001-05-29 09:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428342&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles Schwieters (chuckorama)
Assigned to: Nobody/Anonymous (nobody)
Summary: [IRIX] crash on int->float conversio

Initial Comment:
here is a snippet from a python session running on
IRIX 6.5.11m, compiled with the native compiler

% python
Python 2.1 (#3, May 29 2001, 10:15:29) [C] on irix646
>>> amin = 0; a=1.0; Na=10
>>> xmin = amin * a / Na
Bus error (core dumped)

I also had this problem with version 2.1b2. 

It works fine if I explicitly change the integers to
floats

it runs fine on Linux and Solaris platforms.

----------------------------------------------------------------------

>Comment By: Charles Schwieters (chuckorama)
Date: 2001-05-30 06:07

Message:
Logged In: YES 
user_id=182049

You are so right. Compiling floatobject.c -O1 removes the
problem. (all others use the default -O -OPT:Olimit=0)
The optimizer seems to muck up the call to convert_to_double
in the CONVERT_TO_DOUBLE macro. Suggestions on where to go
from here?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-29 21:24

Message:
Logged In: YES 
user_id=31435

First thing to try with any problem on IRIX is to recompile 
Python with optimization turned off.  That's usually all 
there is to it.  Then, if that fixes it and you feel like 
it, you can play binary search to determine which file 
optimization is breaking (floatobject.c would be my first 
guess).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428342&group_id=5470


From noreply@sourceforge.net  Wed May 30 17:50:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 09:50:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-428724 ] SystemError on import w/ invalid package
Message-ID: <E1559BL-0007sd-00@usw-sf-web3.sourceforge.net>

Bugs item #428724, was updated on 2001-05-30 09:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428724&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Tim Peters (tim_one)
Summary: SystemError on import w/ invalid package

Initial Comment:
This problem occurs with Python 2.1 and Windows 2000.

I created a directory Test with a file foo.py in it.  I
forgot to put an __init__.py in Test.  I ran Python
from the directory that contains Test.

>>> import Test.foo
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: NULL result without error in call_object

If I place an __init__.py in the Test directory, the
import works.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428724&group_id=5470


From noreply@sourceforge.net  Wed May 30 20:39:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 12:39:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-428724 ] SystemError on import w/ invalid package
Message-ID: <E155Bp1-0000yg-00@usw-sf-web2.sourceforge.net>

Bugs item #428724, was updated on 2001-05-30 09:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428724&group_id=5470

Category: Windows
Group: Platform-specific
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Tim Peters (tim_one)
Summary: SystemError on import w/ invalid package

Initial Comment:
This problem occurs with Python 2.1 and Windows 2000.

I created a directory Test with a file foo.py in it.  I
forgot to put an __init__.py in Test.  I ran Python
from the directory that contains Test.

>>> import Test.foo
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: NULL result without error in call_object

If I place an __init__.py in the Test directory, the
import works.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-30 12:39

Message:
Logged In: YES 
user_id=31435

Yes, essentially the same thing was reported earlier in bug 
417093.

It's been fixed; here under current CVS Python:

Python 2.2a0 (#16, May 14 2001, 19:54:03) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import Test.foo
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named Test.foo
>>>


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428724&group_id=5470


From noreply@sourceforge.net  Wed May 30 21:04:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 13:04:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-428795 ] Use absolut paths when importing PYDs
Message-ID: <E155CD4-00020Z-00@usw-sf-web3.sourceforge.net>

Bugs item #428795, was updated on 2001-05-30 13:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428795&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Mark Hammond (mhammond)
Summary: Use absolut paths when importing PYDs

Initial Comment:
As discussed on python-dev:

Windows 95 has a problem with importing PYD files using
relative file names. The fix is easy and Mark Hammond
already provided a patch for this.

I just added the bug report so that the bug and its fix
don't get lost.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428795&group_id=5470


From noreply@sourceforge.net  Wed May 30 22:15:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 14:15:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-428342 ] [IRIX] crash on int->float conversio
Message-ID: <E155DJg-00021A-00@usw-sf-web2.sourceforge.net>

Bugs item #428342, was updated on 2001-05-29 09:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428342&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Charles Schwieters (chuckorama)
Assigned to: Nobody/Anonymous (nobody)
Summary: [IRIX] crash on int->float conversio

Initial Comment:
here is a snippet from a python session running on
IRIX 6.5.11m, compiled with the native compiler

% python
Python 2.1 (#3, May 29 2001, 10:15:29) [C] on irix646
>>> amin = 0; a=1.0; Na=10
>>> xmin = amin * a / Na
Bus error (core dumped)

I also had this problem with version 2.1b2. 

It works fine if I explicitly change the integers to
floats

it runs fine on Linux and Solaris platforms.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-30 14:15

Message:
Logged In: YES 
user_id=31435

I don't see that there's anything we can do about it:  it's 
a compiler-specific optimization error, and you should 
report that to your compiler vendor.  SGI does very 
aggressive optimization and Python users on SGI have had 
similar problems for years (although in different places 
under different releases of the compiler).  By now, they 
should have added Python to their internal compiler 
regression suite!

The code in question looks like standard, portable C to me, 
so there's nothing principled to do I can think of in the 
way of guessing what might make SGI's compiler happier.  If 
you try enough different ways of rewriting the macro I'm 
sure you'll stumble into some way that SGI is happy with.  
I probably wouldn't accept that change back into the Python 
code base, though, as if there's no solid *reason* for the 
change, it will just break again someday.

It's also possible that there's some subtle non-standard 
assumption Python is making here, in which case there is a 
solid reason.  But I don't see one.  If you do, let us know 
and I'll reopen the bug report.


----------------------------------------------------------------------

Comment By: Charles Schwieters (chuckorama)
Date: 2001-05-30 06:07

Message:
Logged In: YES 
user_id=182049

You are so right. Compiling floatobject.c -O1 removes the
problem. (all others use the default -O -OPT:Olimit=0)
The optimizer seems to muck up the call to convert_to_double
in the CONVERT_TO_DOUBLE macro. Suggestions on where to go
from here?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-29 21:24

Message:
Logged In: YES 
user_id=31435

First thing to try with any problem on IRIX is to recompile 
Python with optimization turned off.  That's usually all 
there is to it.  Then, if that fixes it and you feel like 
it, you can play binary search to determine which file 
optimization is breaking (floatobject.c would be my first 
guess).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428342&group_id=5470


From noreply@sourceforge.net  Wed May 30 22:30:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 14:30:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-423472 ] Hang in select.select() and time.sleep()
Message-ID: <E155DXj-0004yS-00@usw-sf-web1.sourceforge.net>

Bugs item #423472, was updated on 2001-05-11 17:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423472&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Seguin (rpseguin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hang in select.select() and time.sleep()

Initial Comment:
Platform:  FreeBSD 4.0
Python version:   2.0 and 2.1  (maybe 1.5.2, haven't
tried)

There is a bug in the select() code that manifests
itself as a hang of the process if the system clock is
adjusted during a call to  select.select() or
time.sleep()  (which uses select())

I'm guessing that this might be related to the
reentrant., thread-safe libc_r.so used by the Python
runtime.


Steps to reproduce:

rseguin% python
Python 2.1 (#1, May 11 2001, 16:54:06)
[GCC 2.95 19990728 (release)] on freebsd4
Type "copyright", "credits" or "license" for more
information.
>>> import time
>>>
time.sleep(10.0)                                                            
(now set the system clock date/time via another shell)

Result is one of two things:
-ether  time.sleep()  (or select.select()) never comes
back
-OR it comes back after the time delta from previous
time before clock adjust and the adjusted time + the
desired sleep time interval.

This bug is more insidious than it may initially seem,
as there are any of a number of time adjusting daemons
(xntpd, ntpd, ...).  This is a nasty bug for daemon
style code in particular, as the daemon appears to be
running, while it is actually just hung.

This bug was in 2.0 and it is still there in 2.1

-Ralph
rpseguin@yahoo.com




----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-30 14:30

Message:
Logged In: NO 

Turns out that the problem IS related to the reentrant
libc_r library that Python links against.  A standalone C
program linked against that same library has the same
problem.

The desired behavior is for select() to go to sleep for the
amount of time specified in the timeval struct, NOT for some
absolute time computed as an offset against the current time
(since the time can change underfoot).



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-29 14:57

Message:
Logged In: YES 
user_id=31392

What happens to a C program if you do the same?  I can't
tell if this is a Python bug or a C library bug, if indeed
it is a bug.  I'm not sure what these functions are supposed
to do when the clock is adjusted.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423472&group_id=5470


From noreply@sourceforge.net  Wed May 30 22:40:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 14:40:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-423472 ] Hang in select.select() and time.sleep()
Message-ID: <E155DhE-00056l-00@usw-sf-web1.sourceforge.net>

Bugs item #423472, was updated on 2001-05-11 17:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423472&group_id=5470

Category: Python Library
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Ralph Seguin (rpseguin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Hang in select.select() and time.sleep()

Initial Comment:
Platform:  FreeBSD 4.0
Python version:   2.0 and 2.1  (maybe 1.5.2, haven't
tried)

There is a bug in the select() code that manifests
itself as a hang of the process if the system clock is
adjusted during a call to  select.select() or
time.sleep()  (which uses select())

I'm guessing that this might be related to the
reentrant., thread-safe libc_r.so used by the Python
runtime.


Steps to reproduce:

rseguin% python
Python 2.1 (#1, May 11 2001, 16:54:06)
[GCC 2.95 19990728 (release)] on freebsd4
Type "copyright", "credits" or "license" for more
information.
>>> import time
>>>
time.sleep(10.0)                                                            
(now set the system clock date/time via another shell)

Result is one of two things:
-ether  time.sleep()  (or select.select()) never comes
back
-OR it comes back after the time delta from previous
time before clock adjust and the adjusted time + the
desired sleep time interval.

This bug is more insidious than it may initially seem,
as there are any of a number of time adjusting daemons
(xntpd, ntpd, ...).  This is a nasty bug for daemon
style code in particular, as the daemon appears to be
running, while it is actually just hung.

This bug was in 2.0 and it is still there in 2.1

-Ralph
rpseguin@yahoo.com




----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-05-30 14:40

Message:
Logged In: YES 
user_id=31435

Thanks for investigating!  I'm closing this as "3rd Party" 
and "Won't Fix" -- fixing a platform-specific select() bug 
isn't something Python can reasonably do.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-30 14:30

Message:
Logged In: NO 

Turns out that the problem IS related to the reentrant
libc_r library that Python links against.  A standalone C
program linked against that same library has the same
problem.

The desired behavior is for select() to go to sleep for the
amount of time specified in the timeval struct, NOT for some
absolute time computed as an offset against the current time
(since the time can change underfoot).



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-29 14:57

Message:
Logged In: YES 
user_id=31392

What happens to a C program if you do the same?  I can't
tell if this is a Python bug or a C library bug, if indeed
it is a bug.  I'm not sure what these functions are supposed
to do when the clock is adjusted.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423472&group_id=5470


From noreply@sourceforge.net  Wed May 30 22:39:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 14:39:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-427604 ] Lang Ref, grammar productions should be hyperlinked
Message-ID: <E155Dgw-0003Ci-00@usw-sf-web3.sourceforge.net>

Bugs item #427604, was updated on 2001-05-26 14:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427604&group_id=5470

Category: Documentation
>Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Lang Ref, grammar productions should be hyperlinked

Initial Comment:
The grammar for  integer and longinteger given in
section 2.4.5 of the Language Reference is missing a
definition for  the "digit" term.

I think, the grammar should have a production like
this:
digit:  "0"..."9"

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-30 14:39

Message:
Logged In: YES 
user_id=3066

(I thought I updated this yesterday, but I guess not.)

I'm re-classifying this as a feature request for hyperlinked productions in the grammar.  I showed Tim a quick prototype yesterday, and will post a revised version shortly at:

http://python.sourceforge.net/devel-docs/ref/ref.html

It's starting to look pretty cool, but there are still glitches.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-26 14:30

Message:
Logged In: YES 
user_id=31435

"digit" is already defined, but in section 2.3 (Identifiers 
and keywords).

Fred, how much unbearable pain would it be to come with a 
(hyperlinked in HTML) grammar production index?  There are 
many cases where a production referenced in one section is 
defined in another, and it's very hard to find the 
definition whenever that occurs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427604&group_id=5470


From noreply@sourceforge.net  Wed May 30 23:30:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 30 May 2001 15:30:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-428795 ] Use absolut paths when importing PYDs
Message-ID: <E155ETr-0005mC-00@usw-sf-web1.sourceforge.net>

Bugs item #428795, was updated on 2001-05-30 13:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428795&group_id=5470

Category: Windows
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Mark Hammond (mhammond)
Summary: Use absolut paths when importing PYDs

Initial Comment:
As discussed on python-dev:

Windows 95 has a problem with importing PYD files using
relative file names. The fix is easy and Mark Hammond
already provided a patch for this.

I just added the bug report so that the bug and its fix
don't get lost.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2001-05-30 15:30

Message:
Logged In: YES 
user_id=14198

dynload_win.c already has been checked in with this fix.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428795&group_id=5470


From noreply@sourceforge.net  Thu May 31 08:25:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 May 2001 00:25:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-428795 ] Use absolut paths when importing PYDs
Message-ID: <E155Mpy-000416-00@usw-sf-web1.sourceforge.net>

Bugs item #428795, was updated on 2001-05-30 13:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428795&group_id=5470

Category: Windows
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Mark Hammond (mhammond)
Summary: Use absolut paths when importing PYDs

Initial Comment:
As discussed on python-dev:

Windows 95 has a problem with importing PYD files using
relative file names. The fix is easy and Mark Hammond
already provided a patch for this.

I just added the bug report so that the bug and its fix
don't get lost.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-31 00:25

Message:
Logged In: YES 
user_id=38388

Ah good. Sorry, must have missed the checkin message.

Thanks.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-05-30 15:30

Message:
Logged In: YES 
user_id=14198

dynload_win.c already has been checked in with this fix.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428795&group_id=5470


From noreply@sourceforge.net  Thu May 31 13:08:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 May 2001 05:08:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-428972 ] any plan for ConfigParser supports XML?
Message-ID: <E155RFC-0001yn-00@usw-sf-web2.sourceforge.net>

Bugs item #428972, was updated on 2001-05-31 05:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428972&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: eXom (jkuan)
Assigned to: Nobody/Anonymous (nobody)
Summary: any plan for ConfigParser supports XML?

Initial Comment:
There are more applications using XML for configuration
file. 
Is there any plan to support this feature in
ConfigParser?

Thanks
Joe

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428972&group_id=5470


From noreply@sourceforge.net  Thu May 31 15:58:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 May 2001 07:58:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-429031 ] Text widget, bindtags and Tabs
Message-ID: <E155TuE-0003wB-00@usw-sf-web2.sourceforge.net>

Bugs item #429031, was updated on 2001-05-31 07:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429031&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alankar Misra (alankar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Text widget, bindtags and Tabs

Initial Comment:
While using a Text widget, if I were to swap the first 
two default elements in the bindtags tuple 
(text._w,'Text') swapped to ('Text',text._w), ie the 
Text widget now recieves all the key events before a 
bound event handler does, the Text widget will eat up 
Tabs and the event handler will never be called. The 
attached py file demonstrates just that. It works with 
all the other keys, why not tabs?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429031&group_id=5470


From noreply@sourceforge.net  Thu May 31 17:20:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 May 2001 09:20:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-429059 ] No docs for os.getenv
Message-ID: <E155VBP-0004oj-00@usw-sf-web2.sourceforge.net>

Bugs item #429059, was updated on 2001-05-31 09:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429059&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Yakov Markovitch (markovitch)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: No docs for os.getenv

Initial Comment:
The os.getenv(), which is present at least over 3 last
Python version, is not documented (though there is a
decent docstring)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429059&group_id=5470


From noreply@sourceforge.net  Thu May 31 18:03:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 May 2001 10:03:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-429070 ] Thread.getDaemon()should be isDaemon()
Message-ID: <E155Vqg-0003Lj-00@usw-sf-web1.sourceforge.net>

Bugs item #429070, was updated on 2001-05-31 10:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429070&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Thread.getDaemon()should be isDaemon()

Initial Comment:
In Python 2.0 (Win32 distribution), the file
Doc/lib/thread-objects.html refers to a getDaemon()
method for the Thread class.  The name of the method
(in Lib/threading.py) is isDaemon(), not getDaemon().


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429070&group_id=5470


From noreply@sourceforge.net  Thu May 31 18:31:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 May 2001 10:31:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-429084 ] Results of running Flawfinder
Message-ID: <E155WHn-0000WW-00@usw-sf-web3.sourceforge.net>

Bugs item #429084, was updated on 2001-05-31 10:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429084&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Results of running Flawfinder

Initial Comment:
I tried running Flawfinder
(http://www.dwheeler.com/flawfinder/) on the Python
source code. SInce I'm not nasty I won't paste *all* of
the errors found, but here some:

/usr/src/python-cvs/Modules/flmodule.c:373 [2] (buffer)
sprintf: does not check for buffer overflows. Use
snprintf or vsnprintf. Risk is low because the source
has a constant maximum length
/usr/src/python-cvs/Modules/posixmodule.c:4191 [3]
(tmpfile) tempnam: temporary file race condition. . 
/usr/src/python-cvs/Modules/posixmodule.c:4237 [3]
(tmpfile) tmpnam: temporary file race condition. . 
/usr/src/python-cvs/Modules/_weakref.c:141 [4] (buffer)
sprintf: does not check for buffer overflows. Use
snprintf or vsnprintf. 
/usr/src/python-cvs/Modules/almodule.c:51 [4] (format)
vsprintf: Potential format string problem. Make Format
string constant. 
/usr/src/python-cvs/Modules/getpath.c:169 [4] (buffer)
strcat: does not check for buffer overflows. Consider
using strncat or strlcat. 

There were lots more - try it and see.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429084&group_id=5470


From noreply@sourceforge.net  Thu May 31 21:24:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 May 2001 13:24:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-429070 ] Thread.getDaemon()should be isDaemon()
Message-ID: <E155Z02-0006IY-00@usw-sf-web1.sourceforge.net>

Bugs item #429070, was updated on 2001-05-31 10:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429070&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Thread.getDaemon()should be isDaemon()

Initial Comment:
In Python 2.0 (Win32 distribution), the file
Doc/lib/thread-objects.html refers to a getDaemon()
method for the Thread class.  The name of the method
(in Lib/threading.py) is isDaemon(), not getDaemon().


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-31 13:24

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libthreading.tex revisions 1.8 and 1.7.12.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429070&group_id=5470


From noreply@sourceforge.net  Thu May 31 21:28:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 31 May 2001 13:28:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-429059 ] No docs for os.getenv()
Message-ID: <E155Z3F-0006LS-00@usw-sf-web1.sourceforge.net>

Bugs item #429059, was updated on 2001-05-31 09:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429059&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Yakov Markovitch (markovitch)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: No docs for os.getenv()

Initial Comment:
The os.getenv(), which is present at least over 3 last
Python version, is not documented (though there is a
decent docstring)

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-31 13:28

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libos.tex revisions 1.55 and 1.53.4.2.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429059&group_id=5470