From noreply@sourceforge.net  Thu Feb  1 00:41:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 31 Jan 2001 16:41:26 -0800
Subject: [Python-bugs-list] [Bug #130656] 'from ... import' error from setup.py
Message-ID: <E14O7oU-00012F-00@usw-sf-web2.sourceforge.net>

Bug #130656, was updated on 2001-Jan-31 16:41
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: bcollar
Assigned to : nobody
Summary: 'from ... import' error from setup.py

Details: on debian 2.2 with a cvs tarball from yesterday (1-30-01), the
build went okay, but the setup.py script gave this:

./python ./setup.py build
Traceback (most recent call last):
  File "./setup.py", line 12, in ?
     from distutils.core import Extension, setup
   File "/usr/src/python/dist/src/Lib/distutils/core.py", line 20, in ?
     from distutils.cmd import Command
  File "/usr/src/python/dist/src/Lib/distutils/cmd.py", line 15, in ?
    from distutils import util, dir_util, file_util, archive_util,
 dep_util
 SyntaxError: 'from ... import *' may only occur in a module scope
make: *** [sharedmods] Error 1


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130656&group_id=5470


From noreply@sourceforge.net  Thu Feb  1 14:53:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Feb 2001 06:53:50 -0800
Subject: [Python-bugs-list] [Bug #129995] segfaults on AIX if configured with threads
Message-ID: <E14OL7O-00075Y-00@usw-sf-web3.sourceforge.net>

Bug #129995, was updated on 2001-Jan-24 16:44
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: bcollar
Assigned to : bwarsaw
Summary: segfaults on AIX if configured with threads

Details: Hi. AIX 4.2.1. ran ./configure --without-gcc
--prefix=/development/utils. make CC=xlC OPT="-O2 -qmaxmem=4000". some of
the make output follows. Let me know if you need all of it.

if test ! -f ../Modules/hassignal;  then echo adding sigcheck.o; ar r
../libpython2.1.a sigcheck.o;  else echo leaving sigcheck.o out; fi
leaving sigcheck.o out
        touch add2lib
        if test -f hassignal;  then echo removing sigcheck.o intrcheck.o; 
ar d ../libpython2.1.a sigcheck.o intrcheck.o 2>/dev/null;  else echo
leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
make: 1254-004 The error code from the last command is 2.
make: 1254-005 Ignored error code 2 from last command.
        ar cr ../libpython2.1.a gcmodule.o  threadmodule.o  posixmodule.o 
_sre.o  signalmodule.o config.o getpath.o main.o getbuildinfo.o
        touch add2lib
        cd Modules; make OPT="-O2 -qmaxmem=4000" python.o
        xlC -O2 -qmaxmem=4000 -I./../Include -I.. -DHAVE_CONFIG_H -c
python.c
        expr `cat buildno` + 1 >buildno1
        mv -f buildno1 buildno
        xlC -c -O2 -qmaxmem=4000 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno` 
./Modules/getbuildinfo.c
        ar cr libpython2.1.a getbuildinfo.o
        ranlib libpython2.1.a
        true
        cd Modules;  make OPT="-O2 -qmaxmem=4000" VERSION="2.1" 
prefix="/development/utils/" exec_prefix="/development/utils/" 
LIBRARY=../libpython2.1.a link
        ./makexp_aix python.exp "" ../libpython2.1.a;  xlC 
-Wl,-bE:python.exp -lld python.o  ../libpython2.1.a   -ldl  -lpthreads -lm 
-o python 
        mv python ../python
        ./python ./setup.py build
pthread_mutex_init: Error 0
pthread_cond_init: Error 0
pthread_mutex_lock[1]: Error 0
make: 1254-059 The signal code from the last command is 11.


Follow-Ups:

Date: 2001-Feb-01 06:53
By: twouters

Comment:
Try making sure configure itself is also run with the same CC and OPT
arguments, by running configure like this (using (ba)sh syntax, should work
in ksh as well):

CC=xlC CFLAGS="-O2 -qmaxmem=4000" ./configure <normalopts>

configure might be mis-detecting some things because of the different
arguments.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129995&group_id=5470


From noreply@sourceforge.net  Thu Feb  1 14:26:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Feb 2001 06:26:33 -0800
Subject: [Python-bugs-list] [Bug #130656] 'from ... import' error from setup.py
Message-ID: <E14OKgz-0005fY-00@usw-sf-web1.sourceforge.net>

Bug #130656, was updated on 2001-Jan-31 16:41
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: bcollar
Assigned to : nobody
Summary: 'from ... import' error from setup.py

Details: on debian 2.2 with a cvs tarball from yesterday (1-30-01), the
build went okay, but the setup.py script gave this:

./python ./setup.py build
Traceback (most recent call last):
  File "./setup.py", line 12, in ?
     from distutils.core import Extension, setup
   File "/usr/src/python/dist/src/Lib/distutils/core.py", line 20, in ?
     from distutils.cmd import Command
  File "/usr/src/python/dist/src/Lib/distutils/cmd.py", line 15, in ?
    from distutils import util, dir_util, file_util, archive_util,
 dep_util
 SyntaxError: 'from ... import *' may only occur in a module scope
make: *** [sharedmods] Error 1


Follow-Ups:

Date: 2001-Feb-01 06:26
By: jhylton

Comment:
disutils.file_util used 'from ... import *' in a function.  it is fixed.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130656&group_id=5470


From noreply@sourceforge.net  Thu Feb  1 16:06:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Feb 2001 08:06:37 -0800
Subject: [Python-bugs-list] [Bug #129740] make html fails in the current CVS tree
Message-ID: <E14OMFp-0006ul-00@usw-sf-web2.sourceforge.net>

Bug #129740, was updated on 2001-Jan-22 16:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: esr
Assigned to : esr
Summary: make html fails in the current CVS tree

Details: Script started on Mon Jan 22 18:49:25 2001
]0;esr@snark.thyrsus.com:
/home/esr/cvs/python/dist/src/Docsnark:~/cvs/python/dist/src/Doc$ make
html

(cd html; make PAPER=letter -f ../html/Makefile)

/home/esr/cvs/python/dist/src/Doc/html

make[1]: Entering directory `/home/esr/cvs/python/dist/src/Doc/html'

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../api/api.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/api:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex api

+++ latex2html -init_file /var/tmp/@16080.0 -dir api
/home/esr/cvs/python/dist/src/Doc/api/api.tex

*** Session transcript and error messages are in api.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../doc/doc.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/doc:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex doc

+++ latex2html -init_file /var/tmp/@16085.0 -dir doc
/home/esr/cvs/python/dist/src/Doc/doc/doc.tex

*** Session transcript and error messages are in doc.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../ext/ext.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/ext:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex ext

+++ latex2html -init_file /var/tmp/@16090.0 -dir ext
/home/esr/cvs/python/dist/src/Doc/ext/ext.tex

*** Session transcript and error messages are in ext.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../lib/lib.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/lib:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex lib

+++ latex2html -init_file /var/tmp/@16095.0 -dir lib
/home/esr/cvs/python/dist/src/Doc/lib/lib.tex

*** Session transcript and error messages are in lib.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../mac/mac.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/mac:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex mac

+++ latex2html -init_file /var/tmp/@16109.0 -dir mac
/home/esr/cvs/python/dist/src/Doc/mac/mac.tex

*** Session transcript and error messages are in mac.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../ref/ref.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/ref:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex ref

+++ latex2html -init_file /var/tmp/@16114.0 -dir ref
/home/esr/cvs/python/dist/src/Doc/ref/ref.tex

*** Session transcript and error messages are in ref.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
--numeric --split 3 ../tut/tut.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/tut:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex tut

+++ latex2html -init_file /var/tmp/@16119.0 -dir tut
/home/esr/cvs/python/dist/src/Doc/tut/tut.tex

*** Session transcript and error messages are in tut.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../inst/inst.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/inst:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex inst

+++ latex2html -init_file /var/tmp/@16124.0 -dir inst
/home/esr/cvs/python/dist/src/Doc/inst/inst.tex

*** Session transcript and error messages are in inst.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../dist/dist.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/dist:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex dist

+++ latex2html -init_file /var/tmp/@16129.0 -dir dist
/home/esr/cvs/python/dist/src/Doc/dist/dist.tex

*** Session transcript and error messages are in dist.how.

../tools/mkmodindex --columns 4 --output modindex.html \

	--address 'See <i><a href="about.html">About this document...</a></i> for
information on suggesting changes.' \

	lib/modindex.html mac/modindex.html

Traceback (most recent call last):

  File "../tools/mkmodindex", line 136, in ?

    main()

  File "../tools/mkmodindex", line 91, in main

    ifp = open(ifn)

IOError: [Errno 2] No such file or directory: 'lib/modindex.html'

make[1]: *** [modindex.html] Error 1

make[1]: Leaving directory `/home/esr/cvs/python/dist/src/Doc/html'

make: *** [html] Error 2

]0;esr@snark.thyrsus.com:
/home/esr/cvs/python/dist/src/Docsnark:~/cvs/python/dist/src/Doc$ exit


Script done on Mon Jan 22 18:50:29 2001


Follow-Ups:

Date: 2001-Feb-01 08:06
By: fdrake

Comment:
There were problems which prevented processing of the lib and ref manuals;
these have now been fixed.

Your transcript seems to indicate something more systemic is happening,
however, and I'm not sure what.  Please do a CVS update and try again.  If
the problem persists, please send me a copies of Doc/html/*.how and
re-assign the bug to me.  If this no longer happens, please close the
bug.

Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129740&group_id=5470


From noreply@sourceforge.net  Thu Feb  1 17:11:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Feb 2001 09:11:59 -0800
Subject: [Python-bugs-list] [Bug #130712] BaseHTTPServer.HTTPServer.serve_forever() is stuck
Message-ID: <E14ONH5-0007Lr-00@usw-sf-web2.sourceforge.net>

Bug #130712, was updated on 2001-Feb-01 09:11
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: danielnuriyev
Assigned to : nobody
Summary: BaseHTTPServer.HTTPServer.serve_forever() is stuck

Details: Python: 2.1a1
Platform: NT4

BaseHTTPServer.HTTPServer.server_forever() is stuck.
It doesn't happen on my other computer with Windows2000.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130712&group_id=5470


From noreply@sourceforge.net  Thu Feb  1 17:21:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Feb 2001 09:21:05 -0800
Subject: [Python-bugs-list] [Bug #129995] segfaults on AIX if configured with threads
Message-ID: <E14ONPt-0006tU-00@usw-sf-web1.sourceforge.net>

Bug #129995, was updated on 2001-Jan-24 16:44
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: bcollar
Assigned to : twouters
Summary: segfaults on AIX if configured with threads

Details: Hi. AIX 4.2.1. ran ./configure --without-gcc
--prefix=/development/utils. make CC=xlC OPT="-O2 -qmaxmem=4000". some of
the make output follows. Let me know if you need all of it.

if test ! -f ../Modules/hassignal;  then echo adding sigcheck.o; ar r
../libpython2.1.a sigcheck.o;  else echo leaving sigcheck.o out; fi
leaving sigcheck.o out
        touch add2lib
        if test -f hassignal;  then echo removing sigcheck.o intrcheck.o; 
ar d ../libpython2.1.a sigcheck.o intrcheck.o 2>/dev/null;  else echo
leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
make: 1254-004 The error code from the last command is 2.
make: 1254-005 Ignored error code 2 from last command.
        ar cr ../libpython2.1.a gcmodule.o  threadmodule.o  posixmodule.o 
_sre.o  signalmodule.o config.o getpath.o main.o getbuildinfo.o
        touch add2lib
        cd Modules; make OPT="-O2 -qmaxmem=4000" python.o
        xlC -O2 -qmaxmem=4000 -I./../Include -I.. -DHAVE_CONFIG_H -c
python.c
        expr `cat buildno` + 1 >buildno1
        mv -f buildno1 buildno
        xlC -c -O2 -qmaxmem=4000 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno` 
./Modules/getbuildinfo.c
        ar cr libpython2.1.a getbuildinfo.o
        ranlib libpython2.1.a
        true
        cd Modules;  make OPT="-O2 -qmaxmem=4000" VERSION="2.1" 
prefix="/development/utils/" exec_prefix="/development/utils/" 
LIBRARY=../libpython2.1.a link
        ./makexp_aix python.exp "" ../libpython2.1.a;  xlC 
-Wl,-bE:python.exp -lld python.o  ../libpython2.1.a   -ldl  -lpthreads -lm 
-o python 
        mv python ../python
        ./python ./setup.py build
pthread_mutex_init: Error 0
pthread_cond_init: Error 0
pthread_mutex_lock[1]: Error 0
make: 1254-059 The signal code from the last command is 11.


Follow-Ups:

Date: 2001-Feb-01 09:21
By: bwarsaw

Comment:
Assigning this to Thomas, since I don't have an AIX machine handy, and he
made the mistake of chiming in. :)
-------------------------------------------------------

Date: 2001-Feb-01 06:53
By: twouters

Comment:
Try making sure configure itself is also run with the same CC and OPT
arguments, by running configure like this (using (ba)sh syntax, should work
in ksh as well):

CC=xlC CFLAGS="-O2 -qmaxmem=4000" ./configure <normalopts>

configure might be mis-detecting some things because of the different
arguments.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129995&group_id=5470


From noreply@sourceforge.net  Thu Feb  1 18:06:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Feb 2001 10:06:38 -0800
Subject: [Python-bugs-list] [Bug #124344] smtplib quoteaddr() has problems with RFC821 source routing
Message-ID: <E14OO7y-0008SO-00@usw-sf-web3.sourceforge.net>

Bug #124344, was updated on 2000-Dec-04 02:50
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Later
Bug Group: None
Priority: 2
Submitted by: carey
Assigned to : bwarsaw
Summary: smtplib quoteaddr() has problems with RFC821 source routing

Details: RFC821 defines source routed SMTP addresses of the form
<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA>.  RFC1123 (STD3) deprecates these kinds of
addresses, but does not forbid them.

If an address like this is passed to smtplib.quoteaddr(), the result is
'<@USC-ISIE.ARPA>', which is useless, and illegal according to RFC821. 
smtplib should probably leave the source routing there, assuming anyone
using an address like this knows what they're doing, and since any SMTP
server "MUST" still accept this syntax.

Alternatively, smtplib could just refuse to deliver to an address like
this, with some justification.  (RFC1123 section 5.2.19.)

In any case, this isn't very important at all.  I'll probably write a patch
when I have some time, using one of the two solutions outlined above.


Follow-Ups:

Date: 2001-Feb-01 10:06
By: bwarsaw

Comment:
While I can appreciate the bug, I don't think it's important enough for us
to spend time working out a fix.  However, I will be more than happy to
review a patch contribution.

I'm going to close this with a resolution of "Later" so we can re-address
it when/if a patch is submitted.
-------------------------------------------------------

Date: 2000-Dec-15 13:36
By: nobody

Comment:
it's not just source routed addresses -- it's any address with more than
one @ sign.  here's another case that needs fixing.

>>> quoteaddr('"/dd.NOTES=CN$=Claudio
Alves$/OU$=RioJaneiro$/O$=ErnstYoung$/C$=BR@EYI-AMERICAS/"@ah01.uk.eyi.com')

'</dd.NOTES=CN$=Claudio
Alves$/OU$=RioJaneiro$/O$=ErnstYoung$/C$=BR@EYI-AMERICAS/@ah01.uk.eyi.com>'

>>> quoteaddr(quoteaddr('"/dd.NOTES=CN$=Claudio
Alves$/OU$=RioJaneiro$/O$=ErnstYoung$/C$=BR@EYI-AMERICAS/"@ah01.uk.eyi.com'))

'</dd.NOTES=CN$=ClaudioAlves$/OU$=RioJaneiro$/O$=ErnstYoung$/C$=BR@EYI-AMERICAS/>'

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

Date: 2000-Dec-06 11:58
By: fdrake

Comment:
Assigned to the mail guy.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=124344&group_id=5470


From noreply@sourceforge.net  Thu Feb  1 19:44:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Feb 2001 11:44:21 -0800
Subject: [Python-bugs-list] [Bug #129827] Mac OSX build of 2.1a needs "-traditional-cpp"
Message-ID: <E14OPeX-0000fG-00@usw-sf-web3.sourceforge.net>

Bug #129827, was updated on 2001-Jan-23 09:34
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 5
Submitted by: sdm7g
Assigned to : fdrake
Summary: Mac OSX build of 2.1a needs "-traditional-cpp"

Details: build of 2.1a1 fails on Mac OSX:

compiling classobject.c generates a syntax error
cc needs "-traditional-cpp" flag 

(This probably should have been in before, but changes
 to classobject uncovered the bug. )

-- Steve

Follow-Ups:

Date: 2001-Feb-01 11:44
By: fdrake

Comment:
Since this appears to only be a issue with the Public Beta, I'm marking
this one "Won't Fix", but adding a note to the platform-specific notes
section of the README file, revision 1.111:

MaxOS X:  You need to add the "-traditional-cpp" option to the
        compiler command line for the MacOS X Public Beta.  This is
        appearantly a bug in the default pre-processor, and is
        expected not to be a problem with future versions.  Run
        configure with "OPT=-traditional-cpp ./configure" to add this
        option.

This can be revisited if the problem will not be fixed in the next (beta or
final) release of MacOS X, or if this problem surfaces under Darwin.
-------------------------------------------------------

Date: 2001-Jan-31 15:45
By: sdm7g

Comment:
Modifying Py_DECREF macro in Include/object.h
does not remove the error. -- Steve.
-------------------------------------------------------

Date: 2001-Jan-31 15:43
By: sdm7g

Comment:
Modifying Py_DECREF macro in Include/object.h
does not remove the error. -- Steve.
-------------------------------------------------------

Date: 2001-Jan-26 21:59
By: fdrake

Comment:
Try changing the first line of the expansion of the Py_DECREF macro to
this:

if (--_Py_RefTotal, (--((op)->ob_refcnt) != 0)) \

(note the additional sets of paretheses around the second half of the test
expression)

I'm not sure this will help, but if it does, that would be nice.
-------------------------------------------------------

Date: 2001-Jan-26 11:43
By: sdm7g

Comment:
Fred, FYI, the specific error message is:

cc -c -g -O2 -Wall -Wstrict-prototypes -fPIC -I. -I./Include
-DHAVE_CONFIG_H  -o Objects/classobject.o Objects/classobject.c
Objects/classobject.c:1415: illegal expression, found `->'
Objects/classobject.c:1415: illegal expression, found `)'
Objects/classobject.c:1415: illegal expression, found `)'
make: *** [Objects/classobject.o] Error 1
  

FYI**2, gcc on macosx supports precompiling headers files and the docs
state:

-traditional-cpp 

Controls which preprocessor is used. The default is cpp_precomp ; if you
specify this flag, the standard GNU cpp will be used instead.

I think it's a bug in the precompiler cpp that
produces the errors.

Since Dan and his pals at apple are the only ones
to have Post public beta builds, and if they change the default, it won't
matter if it's  in
there explicitly (I don't know what the default
for public dist. Darwin is) it won't hurt to 
add it. (But if it's a pain, then after Mar 24,
non-apple folks will be able to get the version
on which it doesn't matter! ) 

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

Date: 2001-Jan-26 09:58
By: fdrake

Comment:
It might be nice to know more about the specific error generated; what in
classobject.c is causing a problem?
-------------------------------------------------------

Date: 2001-Jan-23 22:05
By: dkwolfe

Comment:
Note:  This is only true for Public Beta.  Post public beta builds do not
need this flag. (the bug in the pre-processor has been fixed.)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129827&group_id=5470


From noreply@sourceforge.net  Thu Feb  1 20:04:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Feb 2001 12:04:51 -0800
Subject: [Python-bugs-list] [Bug #130712] BaseHTTPServer.HTTPServer.serve_forever() is stuck
Message-ID: <E14OPyN-0007vz-00@usw-sf-web1.sourceforge.net>

Bug #130712, was updated on 2001-Feb-01 09:11
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: danielnuriyev
Assigned to : nobody
Summary: BaseHTTPServer.HTTPServer.serve_forever() is stuck

Details: Python: 2.1a1
Platform: NT4

BaseHTTPServer.HTTPServer.server_forever() is stuck.
It doesn't happen on my other computer with Windows2000.

Follow-Ups:

Date: 2001-Feb-01 12:04
By: fdrake

Comment:
I don't understand what you mean by "stuck".  Can you provide more
information about how to reproduce (a 5-line script might do the trick).

Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130712&group_id=5470


From noreply@sourceforge.net  Thu Feb  1 20:10:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Feb 2001 12:10:21 -0800
Subject: [Python-bugs-list] [Bug #130029] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E14OQ3h-0007yB-00@usw-sf-web1.sourceforge.net>

Bug #130029, was updated on 2001-Jan-25 02:55
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: [HP-UX] Python chokes on pthread_mutex_init

Details: On an HPUX 11.00:  During "make intstall":

./install-sh -c -m 644 ./Lib/curses/__init__.py
/opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/ascii.py
/opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/has_key.py
/opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/textpad.py
/opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/wrapper.py
/opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/plat-hp-uxB/core
/opt/tmp/Python/lib/python2.0/plat-hp-uxB
./install-sh -c -m 755 ./Lib/plat-hp-uxB/regen
/opt/tmp/Python/lib/python2.0/plat-hp-uxB
        ./install-sh -c -m 644 ./LICENSE
/opt/tmp/Python/lib/python2.0/LICENSE.txt
        PYTHONPATH=/opt/tmp/Python/lib/python2.0 \
                        ./python -tt
/opt/tmp/Python/lib/python2.0/compileall.py /opt/tmp/Python/lib/python2.0
pthread_mutex_init: Invalid argument
sh: 6074 Memory fault(coredump)

----------------------------------------------------------
This fault can be reproduced:

export PYTHONPATH=/opt/tmp/Python/lib/python2.0

/opt/stephie/Python-2.0 > ./python -tt
/opt/tmp/Python/lib/python2.0/compileall.py /opt/tmp/Python/lib/python2.0
pthread_mutex_init: Invalid argument
Memory fault(coredump)



Follow-Ups:

Date: 2001-Feb-01 12:10
By: fdrake

Comment:
This may be the same bug as #110650 (already closed, but not clear that
this was ever actually fixed).

Too bad this was an anonymous report; we can't ask for more information
without an email address.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130029&group_id=5470


From noreply@sourceforge.net  Thu Feb  1 21:53:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Feb 2001 13:53:49 -0800
Subject: [Python-bugs-list] [Bug #130748] re punts on "^*"
Message-ID: <E14ORfp-0000E0-00@usw-sf-web1.sourceforge.net>

Bug #130748, was updated on 2001-Feb-01 13:53
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: Trash
Priority: 5
Submitted by: dspguru
Assigned to : nobody
Summary: re punts on "^*"

Details: I don't know if this is a "bug" or it's a "just don't do that",
but here's something I just learned not to accidently do:

ActivePython 2.0, build 202 (ActiveState Tool Corp.)
based on Python 2.0 (#8, Oct 19 2000, 11:30:05) [MSC 32 bit (Intel)] on
win32
Type "copyright", "credits" or "license" for more information.
>>> import re
>>> r = re.compile('^*')
>>> s = 'asdf'
>>> r.match(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: maximum recursion limit exceeded

I guess in an ideal world, this would somehow be trapped out in re's
compilation process (though maybe that would cause more overhead than it's
worth.)

special-cases-aren't-special-enough-to-trap-out
though-safety-beats-speed-ly y'rs,

=g2

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130748&group_id=5470


From noreply@sourceforge.net  Thu Feb  1 23:00:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Feb 2001 15:00:10 -0800
Subject: [Python-bugs-list] [Bug #130748] re punts on "^*"
Message-ID: <E14OSi2-0001KU-00@usw-sf-web2.sourceforge.net>

Bug #130748, was updated on 2001-Feb-01 13:53
Here is a current snapshot of the bug.

Project: Python
Category: Regular Expressions
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: dspguru
Assigned to : effbot
Summary: re punts on "^*"

Details: I don't know if this is a "bug" or it's a "just don't do that",
but here's something I just learned not to accidently do:

ActivePython 2.0, build 202 (ActiveState Tool Corp.)
based on Python 2.0 (#8, Oct 19 2000, 11:30:05) [MSC 32 bit (Intel)] on
win32
Type "copyright", "credits" or "license" for more information.
>>> import re
>>> r = re.compile('^*')
>>> s = 'asdf'
>>> r.match(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: maximum recursion limit exceeded

I guess in an ideal world, this would somehow be trapped out in re's
compilation process (though maybe that would cause more overhead than it's
worth.)

special-cases-aren't-special-enough-to-trap-out
though-safety-beats-speed-ly y'rs,

=g2

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130748&group_id=5470


From noreply@sourceforge.net  Fri Feb  2 04:23:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 01 Feb 2001 20:23:28 -0800
Subject: [Python-bugs-list] [Bug #130712] BaseHTTPServer.HTTPServer.serve_forever() is stuck
Message-ID: <E14OXku-0002qj-00@usw-sf-web1.sourceforge.net>

Bug #130712, was updated on 2001-Feb-01 09:11
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: danielnuriyev
Assigned to : nobody
Summary: BaseHTTPServer.HTTPServer.serve_forever() is stuck

Details: Python: 2.1a1
Platform: NT4

BaseHTTPServer.HTTPServer.server_forever() is stuck.
It doesn't happen on my other computer with Windows2000.

Follow-Ups:

Date: 2001-Feb-01 20:23
By: fdrake

Comment:
(I should also note that I only have Win2K available myself, so it's not
clear I can actually help.)
-------------------------------------------------------

Date: 2001-Feb-01 12:04
By: fdrake

Comment:
I don't understand what you mean by "stuck".  Can you provide more
information about how to reproduce (a 5-line script might do the trick).

Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130712&group_id=5470


From noreply@sourceforge.net  Fri Feb  2 13:59:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Feb 2001 05:59:25 -0800
Subject: [Python-bugs-list] [Bug #129995] segfaults on AIX if configured with threads
Message-ID: <E14OgkH-00089U-00@usw-sf-web3.sourceforge.net>

Bug #129995, was updated on 2001-Jan-24 16:44
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: bcollar
Assigned to : twouters
Summary: segfaults on AIX if configured with threads

Details: Hi. AIX 4.2.1. ran ./configure --without-gcc
--prefix=/development/utils. make CC=xlC OPT="-O2 -qmaxmem=4000". some of
the make output follows. Let me know if you need all of it.

if test ! -f ../Modules/hassignal;  then echo adding sigcheck.o; ar r
../libpython2.1.a sigcheck.o;  else echo leaving sigcheck.o out; fi
leaving sigcheck.o out
        touch add2lib
        if test -f hassignal;  then echo removing sigcheck.o intrcheck.o; 
ar d ../libpython2.1.a sigcheck.o intrcheck.o 2>/dev/null;  else echo
leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
make: 1254-004 The error code from the last command is 2.
make: 1254-005 Ignored error code 2 from last command.
        ar cr ../libpython2.1.a gcmodule.o  threadmodule.o  posixmodule.o 
_sre.o  signalmodule.o config.o getpath.o main.o getbuildinfo.o
        touch add2lib
        cd Modules; make OPT="-O2 -qmaxmem=4000" python.o
        xlC -O2 -qmaxmem=4000 -I./../Include -I.. -DHAVE_CONFIG_H -c
python.c
        expr `cat buildno` + 1 >buildno1
        mv -f buildno1 buildno
        xlC -c -O2 -qmaxmem=4000 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno` 
./Modules/getbuildinfo.c
        ar cr libpython2.1.a getbuildinfo.o
        ranlib libpython2.1.a
        true
        cd Modules;  make OPT="-O2 -qmaxmem=4000" VERSION="2.1" 
prefix="/development/utils/" exec_prefix="/development/utils/" 
LIBRARY=../libpython2.1.a link
        ./makexp_aix python.exp "" ../libpython2.1.a;  xlC 
-Wl,-bE:python.exp -lld python.o  ../libpython2.1.a   -ldl  -lpthreads -lm 
-o python 
        mv python ../python
        ./python ./setup.py build
pthread_mutex_init: Error 0
pthread_cond_init: Error 0
pthread_mutex_lock[1]: Error 0
make: 1254-059 The signal code from the last command is 11.


Follow-Ups:

Date: 2001-Feb-02 05:59
By: twouters

Comment:
I'd like to note that though I don't have access to AIX myself, I do live
with and share a bed with a system administrator who does, very much so,
many, many hours per week. She doesn't have a *compiler* on AIX, though, so
more than general AIX info and the odd programmers manual is out of the
question.

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

Date: 2001-Feb-01 09:21
By: bwarsaw

Comment:
Assigning this to Thomas, since I don't have an AIX machine handy, and he
made the mistake of chiming in. :)
-------------------------------------------------------

Date: 2001-Feb-01 06:53
By: twouters

Comment:
Try making sure configure itself is also run with the same CC and OPT
arguments, by running configure like this (using (ba)sh syntax, should work
in ksh as well):

CC=xlC CFLAGS="-O2 -qmaxmem=4000" ./configure <normalopts>

configure might be mis-detecting some things because of the different
arguments.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129995&group_id=5470


From noreply@sourceforge.net  Fri Feb  2 15:34:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Feb 2001 07:34:59 -0800
Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c
Message-ID: <E14OiEl-0008A4-00@usw-sf-web2.sourceforge.net>

Bug #128973, was updated on 2001-Jan-15 21:12
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: jpettit
Assigned to : twouters
Summary: OpenBSD Problems with _funlockfile in fileobject.c

Details: When I compile the current CVS version of Python on OpenBSD 2.8, I
get the following linker error:

    ld: _funlockfile: non-function jmpslot
    collect2: ld returned 1 exit status
    *** Error code 1

This function was first added to Python in version 2.97 of "fileobject.c".

Follow-Ups:

Date: 2001-Feb-02 07:34
By: twouters

Comment:
I've volunteered myself to debug this, on OpenBSD, using the provided
account.



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

Date: 2001-Jan-25 10:38
By: ltratt

Comment:
I'd be happy to offer any of the Python developers an account on an OpenBSD
machine if they wish - mail tratt@dcs.kcl.ac.uk
-------------------------------------------------------

Date: 2001-Jan-18 19:32
By: gvanrossum

Comment:
Alas, it seems that this will remain open in 2.1a1.  Hopefully someone else
will be able to fix it once the alpha1 release is out.

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

Date: 2001-Jan-16 11:58
By: jpettit

Comment:
The man page doesn't seem to specify a particular library to link against. 
It only says to include stdio.h.

I'm building Python without any special flags.  I thought threads were
enabled by default, but just for good measure, I ran configure with
--with-threads and got the same results.

I don't see any reference to flockfile/funlockfile in config.log.
-------------------------------------------------------

Date: 2001-Jan-16 11:00
By: twouters

Comment:
Unfortunately, I don't have access to OpenBSD, just FreeBSD and BSDI.
flockfile/funlockfile both work fine there. I suspect it's a header/library
problem: maybe we need to include a separate header/library, which we for
some reason do in the configure process, but not in the linking of Python
(or maybe it needs additional magic to link together with other libraries,
I don't know.)

jpettit, can you check the manpage for funlockfile to see what headerfiles
should be included, and perhaps what to link with ? Also, are you compiling
threaded or unthreaded ? There is a good chance the flockfile/funlockfile
functions are only available in threaded code, or maybe Python is being
compiled half-threaded for some reason. Checking to see the difference
between what config.log and 'make' say might give some hints, too.

Or it could just be an OS bug :P We should be able to figure it out though:
if Python can't *compile* with those functions, neither should configure.

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

Date: 2001-Jan-16 09:56
By: jpettit

Comment:
I'd be happy to help however I can.  However, autoconf is black magic to
me.  

I think that funlockfile is supposed to be available...there is even a man
page dated 20 August 1998.  This may be another case of OpenBSD improperly
integrating components from the other BSDs.

Please let me know what I can do.
-------------------------------------------------------

Date: 2001-Jan-16 05:28
By: gvanrossum

Comment:
It's gotta be more complicated that that.  The configure script has a test
program that calls flockfile(), getc_unlocked(), and funlockfile().  Only
if this test program links successfully does it decide to use
getc_unlocked().  (Making the test depend on successfully *running* it
shouldn't make a difference -- the user here got a link-time error.)

jpettit, is there a way you could find out why the configure test succeeds
but then you get a link error linking Python?

I'll also ask Thomas Wouters to look into this.

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

Date: 2001-Jan-15 22:19
By: tim_one

Comment:
Ho ho ho:  so this means some flavor of Unix has getc_unlocked() but not
the flockfile() and funlockfile() that are supposed to come with it?  Man,
Windows looks better every day <wink> -- and so does the
getline_via_fgets() hack ...

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470


From noreply@sourceforge.net  Fri Feb  2 15:54:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Feb 2001 07:54:30 -0800
Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c
Message-ID: <E14OiXe-0008KE-00@usw-sf-web2.sourceforge.net>

Bug #128973, was updated on 2001-Jan-15 21:12
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: jpettit
Assigned to : twouters
Summary: OpenBSD Problems with _funlockfile in fileobject.c

Details: When I compile the current CVS version of Python on OpenBSD 2.8, I
get the following linker error:

    ld: _funlockfile: non-function jmpslot
    collect2: ld returned 1 exit status
    *** Error code 1

This function was first added to Python in version 2.97 of "fileobject.c".

Follow-Ups:

Date: 2001-Feb-02 07:54
By: twouters

Comment:
Testing the current CVS tree on ltratt's offered OpenBSD machine
(OpenBSD-stable 2.8 on i386) I can't reproduce the problem. I do see these
slightly suspicious messages though:

ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x2d5ec for
"_flockfile"
ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x2d633 for
"_funlockfile"

I suspect this is fixed by an update/patch/whatever OpenBSD uses to one of
the development tools (gcc, ld, libc, whatever OpenBSD uses :)
Unless there was some other difference between the machines of jpettit and
ltratt ?

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

Date: 2001-Feb-02 07:34
By: twouters

Comment:
I've volunteered myself to debug this, on OpenBSD, using the provided
account.



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

Date: 2001-Jan-25 10:38
By: ltratt

Comment:
I'd be happy to offer any of the Python developers an account on an OpenBSD
machine if they wish - mail tratt@dcs.kcl.ac.uk
-------------------------------------------------------

Date: 2001-Jan-18 19:32
By: gvanrossum

Comment:
Alas, it seems that this will remain open in 2.1a1.  Hopefully someone else
will be able to fix it once the alpha1 release is out.

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

Date: 2001-Jan-16 11:58
By: jpettit

Comment:
The man page doesn't seem to specify a particular library to link against. 
It only says to include stdio.h.

I'm building Python without any special flags.  I thought threads were
enabled by default, but just for good measure, I ran configure with
--with-threads and got the same results.

I don't see any reference to flockfile/funlockfile in config.log.
-------------------------------------------------------

Date: 2001-Jan-16 11:00
By: twouters

Comment:
Unfortunately, I don't have access to OpenBSD, just FreeBSD and BSDI.
flockfile/funlockfile both work fine there. I suspect it's a header/library
problem: maybe we need to include a separate header/library, which we for
some reason do in the configure process, but not in the linking of Python
(or maybe it needs additional magic to link together with other libraries,
I don't know.)

jpettit, can you check the manpage for funlockfile to see what headerfiles
should be included, and perhaps what to link with ? Also, are you compiling
threaded or unthreaded ? There is a good chance the flockfile/funlockfile
functions are only available in threaded code, or maybe Python is being
compiled half-threaded for some reason. Checking to see the difference
between what config.log and 'make' say might give some hints, too.

Or it could just be an OS bug :P We should be able to figure it out though:
if Python can't *compile* with those functions, neither should configure.

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

Date: 2001-Jan-16 09:56
By: jpettit

Comment:
I'd be happy to help however I can.  However, autoconf is black magic to
me.  

I think that funlockfile is supposed to be available...there is even a man
page dated 20 August 1998.  This may be another case of OpenBSD improperly
integrating components from the other BSDs.

Please let me know what I can do.
-------------------------------------------------------

Date: 2001-Jan-16 05:28
By: gvanrossum

Comment:
It's gotta be more complicated that that.  The configure script has a test
program that calls flockfile(), getc_unlocked(), and funlockfile().  Only
if this test program links successfully does it decide to use
getc_unlocked().  (Making the test depend on successfully *running* it
shouldn't make a difference -- the user here got a link-time error.)

jpettit, is there a way you could find out why the configure test succeeds
but then you get a link error linking Python?

I'll also ask Thomas Wouters to look into this.

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

Date: 2001-Jan-15 22:19
By: tim_one

Comment:
Ho ho ho:  so this means some flavor of Unix has getc_unlocked() but not
the flockfile() and funlockfile() that are supposed to come with it?  Man,
Windows looks better every day <wink> -- and so does the
getline_via_fgets() hack ...

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470


From noreply@sourceforge.net  Fri Feb  2 19:35:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 02 Feb 2001 11:35:11 -0800
Subject: [Python-bugs-list] [Bug #130006] /test/tokenize_tests_.py minor bug
Message-ID: <E14OlzD-0000iI-00@usw-sf-web1.sourceforge.net>

Bug #130006, was updated on 2001-Jan-24 20:00
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Submitted by: nobody
Assigned to : jhylton
Summary: /test/tokenize_tests_.py minor bug

Details: There is a minor error on line 147 in the module
/test/tokenize_tests.py of
the new 2.1alpha1.  The function d01v has the parameter name "rest"
repeated
in the function definition.  This gives an error message when that
function
is reached during  "make install" on a Debian 2.2 (potato) Linux system.


Follow-Ups:

Date: 2001-Jan-31 12:19
By: jhylton

Comment:
I can't reproduce this problem on my system.  The file definitely
has duplicate arguments, but that shouldn't affect the tokenize test. 
Can you provide the exact error output you see?

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130006&group_id=5470


From noreply@sourceforge.net  Sat Feb  3 17:40:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 03 Feb 2001 09:40:53 -0800
Subject: [Python-bugs-list] [Bug #130006] /test/tokenize_tests_.py minor bug
Message-ID: <E14P6g9-0002Vj-00@usw-sf-web3.sourceforge.net>

Bug #130006, was updated on 2001-Jan-24 20:00
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Submitted by: nobody
Assigned to : jhylton
Summary: /test/tokenize_tests_.py minor bug

Details: There is a minor error on line 147 in the module
/test/tokenize_tests.py of
the new 2.1alpha1.  The function d01v has the parameter name "rest"
repeated
in the function definition.  This gives an error message when that
function
is reached during  "make install" on a Debian 2.2 (potato) Linux system.


Follow-Ups:

Date: 2001-Feb-03 09:40
By: nobody

Comment:
The exact message appears during the "make install" process as follows:

Compiling /usr/local/lib/python2.1/test/tokenize_tests.py ...
SyntaxError: duplicate argument 'rest' in function definition

The message does NOT cause the install to abort.

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

Date: 2001-Jan-31 12:19
By: jhylton

Comment:
I can't reproduce this problem on my system.  The file definitely
has duplicate arguments, but that shouldn't affect the tokenize test. 
Can you provide the exact error output you see?

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130006&group_id=5470


From noreply@sourceforge.net  Sun Feb  4 14:28:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Feb 2001 06:28:51 -0800
Subject: [Python-bugs-list] [Bug #129740] mkhowto needs better diagnostic messages
Message-ID: <E14PQ9r-0001wc-00@usw-sf-web3.sourceforge.net>

Bug #129740, was updated on 2001-Jan-22 16:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 6
Submitted by: esr
Assigned to : esr
Summary: mkhowto needs better diagnostic messages

Details: Script started on Mon Jan 22 18:49:25 2001
]0;esr@snark.thyrsus.com:
/home/esr/cvs/python/dist/src/Docsnark:~/cvs/python/dist/src/Doc$ make
html

(cd html; make PAPER=letter -f ../html/Makefile)

/home/esr/cvs/python/dist/src/Doc/html

make[1]: Entering directory `/home/esr/cvs/python/dist/src/Doc/html'

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../api/api.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/api:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex api

+++ latex2html -init_file /var/tmp/@16080.0 -dir api
/home/esr/cvs/python/dist/src/Doc/api/api.tex

*** Session transcript and error messages are in api.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../doc/doc.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/doc:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex doc

+++ latex2html -init_file /var/tmp/@16085.0 -dir doc
/home/esr/cvs/python/dist/src/Doc/doc/doc.tex

*** Session transcript and error messages are in doc.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../ext/ext.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/ext:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex ext

+++ latex2html -init_file /var/tmp/@16090.0 -dir ext
/home/esr/cvs/python/dist/src/Doc/ext/ext.tex

*** Session transcript and error messages are in ext.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../lib/lib.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/lib:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex lib

+++ latex2html -init_file /var/tmp/@16095.0 -dir lib
/home/esr/cvs/python/dist/src/Doc/lib/lib.tex

*** Session transcript and error messages are in lib.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../mac/mac.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/mac:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex mac

+++ latex2html -init_file /var/tmp/@16109.0 -dir mac
/home/esr/cvs/python/dist/src/Doc/mac/mac.tex

*** Session transcript and error messages are in mac.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../ref/ref.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/ref:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex ref

+++ latex2html -init_file /var/tmp/@16114.0 -dir ref
/home/esr/cvs/python/dist/src/Doc/ref/ref.tex

*** Session transcript and error messages are in ref.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
--numeric --split 3 ../tut/tut.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/tut:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex tut

+++ latex2html -init_file /var/tmp/@16119.0 -dir tut
/home/esr/cvs/python/dist/src/Doc/tut/tut.tex

*** Session transcript and error messages are in tut.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../inst/inst.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/inst:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex inst

+++ latex2html -init_file /var/tmp/@16124.0 -dir inst
/home/esr/cvs/python/dist/src/Doc/inst/inst.tex

*** Session transcript and error messages are in inst.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../dist/dist.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/dist:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex dist

+++ latex2html -init_file /var/tmp/@16129.0 -dir dist
/home/esr/cvs/python/dist/src/Doc/dist/dist.tex

*** Session transcript and error messages are in dist.how.

../tools/mkmodindex --columns 4 --output modindex.html \

	--address 'See <i><a href="about.html">About this document...</a></i> for
information on suggesting changes.' \

	lib/modindex.html mac/modindex.html

Traceback (most recent call last):

  File "../tools/mkmodindex", line 136, in ?

    main()

  File "../tools/mkmodindex", line 91, in main

    ifp = open(ifn)

IOError: [Errno 2] No such file or directory: 'lib/modindex.html'

make[1]: *** [modindex.html] Error 1

make[1]: Leaving directory `/home/esr/cvs/python/dist/src/Doc/html'

make: *** [html] Error 2

]0;esr@snark.thyrsus.com:
/home/esr/cvs/python/dist/src/Docsnark:~/cvs/python/dist/src/Doc$ exit


Script done on Mon Jan 22 18:50:29 2001


Follow-Ups:

Date: 2001-Feb-04 06:28
By: fdrake

Comment:
Examination of Eric's Doc/html/*.how files (generated by Doc/tools/mkhowto)
indicate that he doesn't have LaTeX2HTML installed, or at least not on his
path.

I'll try and make Doc/tools/mkhowto have better presentation of failure
information.

(Changed summary to reflect this diagnosis.)
-------------------------------------------------------

Date: 2001-Feb-01 08:06
By: fdrake

Comment:
There were problems which prevented processing of the lib and ref manuals;
these have now been fixed.

Your transcript seems to indicate something more systemic is happening,
however, and I'm not sure what.  Please do a CVS update and try again.  If
the problem persists, please send me a copies of Doc/html/*.how and
re-assign the bug to me.  If this no longer happens, please close the
bug.

Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129740&group_id=5470


From noreply@sourceforge.net  Sun Feb  4 14:29:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Feb 2001 06:29:23 -0800
Subject: [Python-bugs-list] [Bug #129740] mkhowto needs better diagnostic messages
Message-ID: <E14PQAN-0001wu-00@usw-sf-web3.sourceforge.net>

Bug #129740, was updated on 2001-Jan-22 16:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 6
Submitted by: esr
Assigned to : fdrake
Summary: mkhowto needs better diagnostic messages

Details: Script started on Mon Jan 22 18:49:25 2001
]0;esr@snark.thyrsus.com:
/home/esr/cvs/python/dist/src/Docsnark:~/cvs/python/dist/src/Doc$ make
html

(cd html; make PAPER=letter -f ../html/Makefile)

/home/esr/cvs/python/dist/src/Doc/html

make[1]: Entering directory `/home/esr/cvs/python/dist/src/Doc/html'

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../api/api.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/api:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex api

+++ latex2html -init_file /var/tmp/@16080.0 -dir api
/home/esr/cvs/python/dist/src/Doc/api/api.tex

*** Session transcript and error messages are in api.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../doc/doc.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/doc:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex doc

+++ latex2html -init_file /var/tmp/@16085.0 -dir doc
/home/esr/cvs/python/dist/src/Doc/doc/doc.tex

*** Session transcript and error messages are in doc.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../ext/ext.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/ext:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex ext

+++ latex2html -init_file /var/tmp/@16090.0 -dir ext
/home/esr/cvs/python/dist/src/Doc/ext/ext.tex

*** Session transcript and error messages are in ext.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../lib/lib.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/lib:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex lib

+++ latex2html -init_file /var/tmp/@16095.0 -dir lib
/home/esr/cvs/python/dist/src/Doc/lib/lib.tex

*** Session transcript and error messages are in lib.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../mac/mac.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/mac:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex mac

+++ latex2html -init_file /var/tmp/@16109.0 -dir mac
/home/esr/cvs/python/dist/src/Doc/mac/mac.tex

*** Session transcript and error messages are in mac.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../ref/ref.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/ref:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex ref

+++ latex2html -init_file /var/tmp/@16114.0 -dir ref
/home/esr/cvs/python/dist/src/Doc/ref/ref.tex

*** Session transcript and error messages are in ref.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
--numeric --split 3 ../tut/tut.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/tut:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex tut

+++ latex2html -init_file /var/tmp/@16119.0 -dir tut
/home/esr/cvs/python/dist/src/Doc/tut/tut.tex

*** Session transcript and error messages are in tut.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../inst/inst.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/inst:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex inst

+++ latex2html -init_file /var/tmp/@16124.0 -dir inst
/home/esr/cvs/python/dist/src/Doc/inst/inst.tex

*** Session transcript and error messages are in inst.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../dist/dist.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/dist:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex dist

+++ latex2html -init_file /var/tmp/@16129.0 -dir dist
/home/esr/cvs/python/dist/src/Doc/dist/dist.tex

*** Session transcript and error messages are in dist.how.

../tools/mkmodindex --columns 4 --output modindex.html \

	--address 'See <i><a href="about.html">About this document...</a></i> for
information on suggesting changes.' \

	lib/modindex.html mac/modindex.html

Traceback (most recent call last):

  File "../tools/mkmodindex", line 136, in ?

    main()

  File "../tools/mkmodindex", line 91, in main

    ifp = open(ifn)

IOError: [Errno 2] No such file or directory: 'lib/modindex.html'

make[1]: *** [modindex.html] Error 1

make[1]: Leaving directory `/home/esr/cvs/python/dist/src/Doc/html'

make: *** [html] Error 2

]0;esr@snark.thyrsus.com:
/home/esr/cvs/python/dist/src/Docsnark:~/cvs/python/dist/src/Doc$ exit


Script done on Mon Jan 22 18:50:29 2001


Follow-Ups:

Date: 2001-Feb-04 06:29
By: fdrake

Comment:
(And assign the bug back to me as well...)
-------------------------------------------------------

Date: 2001-Feb-04 06:28
By: fdrake

Comment:
Examination of Eric's Doc/html/*.how files (generated by Doc/tools/mkhowto)
indicate that he doesn't have LaTeX2HTML installed, or at least not on his
path.

I'll try and make Doc/tools/mkhowto have better presentation of failure
information.

(Changed summary to reflect this diagnosis.)
-------------------------------------------------------

Date: 2001-Feb-01 08:06
By: fdrake

Comment:
There were problems which prevented processing of the lib and ref manuals;
these have now been fixed.

Your transcript seems to indicate something more systemic is happening,
however, and I'm not sure what.  Please do a CVS update and try again.  If
the problem persists, please send me a copies of Doc/html/*.how and
re-assign the bug to me.  If this no longer happens, please close the
bug.

Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129740&group_id=5470


From noreply@sourceforge.net  Sun Feb  4 15:23:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Feb 2001 07:23:01 -0800
Subject: [Python-bugs-list] [Bug #129740] mkhowto needs better diagnostic messages
Message-ID: <E14PR0H-0003Qm-00@usw-sf-web3.sourceforge.net>

Bug #129740, was updated on 2001-Jan-22 16:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 6
Submitted by: esr
Assigned to : fdrake
Summary: mkhowto needs better diagnostic messages

Details: Script started on Mon Jan 22 18:49:25 2001
]0;esr@snark.thyrsus.com:
/home/esr/cvs/python/dist/src/Docsnark:~/cvs/python/dist/src/Doc$ make
html

(cd html; make PAPER=letter -f ../html/Makefile)

/home/esr/cvs/python/dist/src/Doc/html

make[1]: Entering directory `/home/esr/cvs/python/dist/src/Doc/html'

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../api/api.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/api:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex api

+++ latex2html -init_file /var/tmp/@16080.0 -dir api
/home/esr/cvs/python/dist/src/Doc/api/api.tex

*** Session transcript and error messages are in api.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../doc/doc.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/doc:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex doc

+++ latex2html -init_file /var/tmp/@16085.0 -dir doc
/home/esr/cvs/python/dist/src/Doc/doc/doc.tex

*** Session transcript and error messages are in doc.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../ext/ext.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/ext:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex ext

+++ latex2html -init_file /var/tmp/@16090.0 -dir ext
/home/esr/cvs/python/dist/src/Doc/ext/ext.tex

*** Session transcript and error messages are in ext.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../lib/lib.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/lib:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex lib

+++ latex2html -init_file /var/tmp/@16095.0 -dir lib
/home/esr/cvs/python/dist/src/Doc/lib/lib.tex

*** Session transcript and error messages are in lib.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../mac/mac.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/mac:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex mac

+++ latex2html -init_file /var/tmp/@16109.0 -dir mac
/home/esr/cvs/python/dist/src/Doc/mac/mac.tex

*** Session transcript and error messages are in mac.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../ref/ref.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/ref:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex ref

+++ latex2html -init_file /var/tmp/@16114.0 -dir ref
/home/esr/cvs/python/dist/src/Doc/ref/ref.tex

*** Session transcript and error messages are in ref.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
--numeric --split 3 ../tut/tut.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/tut:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex tut

+++ latex2html -init_file /var/tmp/@16119.0 -dir tut
/home/esr/cvs/python/dist/src/Doc/tut/tut.tex

*** Session transcript and error messages are in tut.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../inst/inst.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/inst:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex inst

+++ latex2html -init_file /var/tmp/@16124.0 -dir inst
/home/esr/cvs/python/dist/src/Doc/inst/inst.tex

*** Session transcript and error messages are in inst.how.

../tools/mkhowto --about ../html/stdabout.dat --address 'See <i><a
href="about.html">About this document...</a></i> for information on
suggesting changes.' --up-link ../index.html --up-title "Python
Documentation Index" --global-module-index "../modindex.html" --html
../dist/dist.tex

+++
TEXINPUTS=/home/esr/cvs/python/dist/src/Doc/dist:/home/esr/cvs/python/dist/src/Doc/paper-letter:/home/esr/cvs/python/dist/src/Doc/texinputs:

+++ latex dist

+++ latex2html -init_file /var/tmp/@16129.0 -dir dist
/home/esr/cvs/python/dist/src/Doc/dist/dist.tex

*** Session transcript and error messages are in dist.how.

../tools/mkmodindex --columns 4 --output modindex.html \

	--address 'See <i><a href="about.html">About this document...</a></i> for
information on suggesting changes.' \

	lib/modindex.html mac/modindex.html

Traceback (most recent call last):

  File "../tools/mkmodindex", line 136, in ?

    main()

  File "../tools/mkmodindex", line 91, in main

    ifp = open(ifn)

IOError: [Errno 2] No such file or directory: 'lib/modindex.html'

make[1]: *** [modindex.html] Error 1

make[1]: Leaving directory `/home/esr/cvs/python/dist/src/Doc/html'

make: *** [html] Error 2

]0;esr@snark.thyrsus.com:
/home/esr/cvs/python/dist/src/Docsnark:~/cvs/python/dist/src/Doc$ exit


Script done on Mon Jan 22 18:50:29 2001


Follow-Ups:

Date: 2001-Feb-04 07:23
By: fdrake

Comment:
Fixed in Doc/tools/mkhowto revision 1.21.

When an external command returns a non-zero exit code, the entire
transcript from that command (stdout & stderr) is dumped to mkhowto's
stderr.
-------------------------------------------------------

Date: 2001-Feb-04 06:29
By: fdrake

Comment:
(And assign the bug back to me as well...)
-------------------------------------------------------

Date: 2001-Feb-04 06:28
By: fdrake

Comment:
Examination of Eric's Doc/html/*.how files (generated by Doc/tools/mkhowto)
indicate that he doesn't have LaTeX2HTML installed, or at least not on his
path.

I'll try and make Doc/tools/mkhowto have better presentation of failure
information.

(Changed summary to reflect this diagnosis.)
-------------------------------------------------------

Date: 2001-Feb-01 08:06
By: fdrake

Comment:
There were problems which prevented processing of the lib and ref manuals;
these have now been fixed.

Your transcript seems to indicate something more systemic is happening,
however, and I'm not sure what.  Please do a CVS update and try again.  If
the problem persists, please send me a copies of Doc/html/*.how and
re-assign the bug to me.  If this no longer happens, please close the
bug.

Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129740&group_id=5470


From noreply@sourceforge.net  Mon Feb  5 07:50:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 04 Feb 2001 23:50:02 -0800
Subject: [Python-bugs-list] [Bug #130712] BaseHTTPServer.HTTPServer.serve_forever() is stuck
Message-ID: <E14PgPS-000143-00@usw-sf-web2.sourceforge.net>

Bug #130712, was updated on 2001-Feb-01 09:11
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: danielnuriyev
Assigned to : nobody
Summary: BaseHTTPServer.HTTPServer.serve_forever() is stuck

Details: Python: 2.1a1
Platform: NT4

BaseHTTPServer.HTTPServer.server_forever() is stuck.
It doesn't happen on my other computer with Windows2000.

Follow-Ups:

Date: 2001-Feb-04 23:50
By: danielnuriyev

Comment:
import BaseHTTPServer, SimpleHTTPServer

server_class=BaseHTTPServer.HTTPServer
handler_class=SimpleHTTPServer.SimpleHTTPRequestHandler
server_address = ('name_of_localhost', 8080)
httpd = server_class(server_address, handler_class)
httpd.serve_forever()
----------------------
When I run the above script in NT, I have to "End Process" of Python.

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

Date: 2001-Feb-01 20:23
By: fdrake

Comment:
(I should also note that I only have Win2K available myself, so it's not
clear I can actually help.)
-------------------------------------------------------

Date: 2001-Feb-01 12:04
By: fdrake

Comment:
I don't understand what you mean by "stuck".  Can you provide more
information about how to reproduce (a 5-line script might do the trick).

Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130712&group_id=5470


From noreply@sourceforge.net  Mon Feb  5 09:54:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Feb 2001 01:54:16 -0800
Subject: [Python-bugs-list] [Bug #131064] sys.path not set correctly in embedded python interpreter.
Message-ID: <E14PiLg-0003wy-00@usw-sf-web1.sourceforge.net>

Bug #131064, was updated on 2001-Feb-05 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: theller
Assigned to : nobody
Summary: sys.path not set correctly in embedded python interpreter.

Details: sys.path is not set correctly in an embedded python interpreter
under the following conditions:
- win98, win95 (NOT NT or win2000)
- There are no subkeys present in the registry under
HKLM\Software\Python\PythonCore\x.x\PythonPath
  (in other words, win32all is NOT installed)

The call to 
			rc = RegQueryValueEx(newKey, NULL, 0, NULL, 
			                     (LPBYTE)szCur, &dataSize);
in PC\getpathp.c, line 307 fails with error code 234 (More data is
available).
There is no check for an error.
The result is that pythonpath is not zero terminated, and contains
garbage.
The call fails because the buffer size specified in dataSize is one byte
too small.
It does not fail on NT or 2000, because dataSize (as got by the call to
RegQueryInfoKey)
seems to be enough for a UNICODE string.

This bug is also already in Python2.0.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131064&group_id=5470


From noreply@sourceforge.net  Mon Feb  5 15:18:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Feb 2001 07:18:54 -0800
Subject: [Python-bugs-list] [Bug #130712] BaseHTTPServer.HTTPServer.serve_forever() is stuck
Message-ID: <E14PnPq-0005XT-00@usw-sf-web3.sourceforge.net>

Bug #130712, was updated on 2001-Feb-01 09:11
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Submitted by: danielnuriyev
Assigned to : gvanrossum
Summary: BaseHTTPServer.HTTPServer.serve_forever() is stuck

Details: Python: 2.1a1
Platform: NT4

BaseHTTPServer.HTTPServer.server_forever() is stuck.
It doesn't happen on my other computer with Windows2000.

Follow-Ups:

Date: 2001-Feb-05 07:18
By: gvanrossum

Comment:
Well, the name of the function is "serve_forever()".. and that's what it
does.  I agree that it's a nuisance that you can't kill it with Control-C
(have you tried Control-Break?), but this is not a bug in Python.

I'm closing this bug report as "Not a bug" and "Wont Fix".
-------------------------------------------------------

Date: 2001-Feb-04 23:50
By: danielnuriyev

Comment:
import BaseHTTPServer, SimpleHTTPServer

server_class=BaseHTTPServer.HTTPServer
handler_class=SimpleHTTPServer.SimpleHTTPRequestHandler
server_address = ('name_of_localhost', 8080)
httpd = server_class(server_address, handler_class)
httpd.serve_forever()
----------------------
When I run the above script in NT, I have to "End Process" of Python.

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

Date: 2001-Feb-01 20:23
By: fdrake

Comment:
(I should also note that I only have Win2K available myself, so it's not
clear I can actually help.)
-------------------------------------------------------

Date: 2001-Feb-01 12:04
By: fdrake

Comment:
I don't understand what you mean by "stuck".  Can you provide more
information about how to reproduce (a 5-line script might do the trick).

Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130712&group_id=5470


From noreply@sourceforge.net  Mon Feb  5 19:53:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Feb 2001 11:53:00 -0800
Subject: [Python-bugs-list] [Bug #131064] sys.path not set correctly in embedded python interpreter.
Message-ID: <E14Prh6-0006zF-00@usw-sf-web2.sourceforge.net>

Bug #131064, was updated on 2001-Feb-05 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: theller
Assigned to : mhammond
Summary: sys.path not set correctly in embedded python interpreter.

Details: sys.path is not set correctly in an embedded python interpreter
under the following conditions:
- win98, win95 (NOT NT or win2000)
- There are no subkeys present in the registry under
HKLM\Software\Python\PythonCore\x.x\PythonPath
  (in other words, win32all is NOT installed)

The call to 
			rc = RegQueryValueEx(newKey, NULL, 0, NULL, 
			                     (LPBYTE)szCur, &dataSize);
in PC\getpathp.c, line 307 fails with error code 234 (More data is
available).
There is no check for an error.
The result is that pythonpath is not zero terminated, and contains
garbage.
The call fails because the buffer size specified in dataSize is one byte
too small.
It does not fail on NT or 2000, because dataSize (as got by the call to
RegQueryInfoKey)
seems to be enough for a UNICODE string.

This bug is also already in Python2.0.


Follow-Ups:

Date: 2001-Feb-05 11:52
By: tim_one

Comment:
Assigned to Mark.  Mark, I only skimmed this.  Assigned to you cuz I'll be
out of town the rest of the week.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131064&group_id=5470


From noreply@sourceforge.net  Mon Feb  5 20:51:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Feb 2001 12:51:05 -0800
Subject: [Python-bugs-list] [Bug #131170] make install fails on macosx for Python-2.1a2
Message-ID: <E14PsbJ-0000db-00@usw-sf-web1.sourceforge.net>

Bug #131170, was updated on 2001-Feb-05 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: sdm7g
Assigned to : nobody
Summary: make install fails on macosx for Python-2.1a2

Details: Python-2.1a2 on macosx 
make install fails trying to ranlib the shared library:

ranlib: file: /usr/local/lib/python2.1/config/libpython2.1.dylib is not an
archive

(This bug wasn't in 2.0, and I don't think was in 2.1a1.)

-- Steve M.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131170&group_id=5470


From noreply@sourceforge.net  Mon Feb  5 21:12:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Feb 2001 13:12:48 -0800
Subject: [Python-bugs-list] [Bug #131170] make install fails on macosx for Python-2.1a2
Message-ID: <E14PswK-0000p3-00@usw-sf-web1.sourceforge.net>

Bug #131170, was updated on 2001-Feb-05 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: sdm7g
Assigned to : nobody
Summary: make install fails on macosx for Python-2.1a2

Details: Python-2.1a2 on macosx 
make install fails trying to ranlib the shared library:

ranlib: file: /usr/local/lib/python2.1/config/libpython2.1.dylib is not an
archive

(This bug wasn't in 2.0, and I don't think was in 2.1a1.)

-- Steve M.

Follow-Ups:

Date: 2001-Feb-05 13:12
By: nobody

Comment:
Commenting out the $(RANLIB) line in the
install section of Makefile seems to fix the problem on macosx, but I don't
know if it is a problemon any other platforms. 

       @if test -d $(LDLIBRARY); then :; else \
                $(INSTALL_DATA) $(LDLIBRARY) $(LIBPL)/$(LDLIBRARY) ; \
#               $(RANLIB) $(LIBPL)/$(LDLIBRARY) ; \

-- Steve M.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131170&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 02:35:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Feb 2001 18:35:15 -0800
Subject: [Python-bugs-list] [Bug #131204] fork()/execv() IDE Crash
Message-ID: <E14PxyN-0002uM-00@usw-sf-web3.sourceforge.net>

Bug #131204, was updated on 2001-Feb-05 18:35
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: fork()/execv() IDE Crash

Details: I'm just learning the fork()/execv() business and i'm sure this
code is crappy... but it does crash IDLE on Windows 98
#system test
import os
MyList = ['127.0.0.1']
while 1:
    
    os.execv('C:\Windows\ping', MyList )
    os.fork()


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131204&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 02:36:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Feb 2001 18:36:15 -0800
Subject: [Python-bugs-list] [Bug #131204] fork()/execv() IDE Crash
Message-ID: <E14PxzL-0002uq-00@usw-sf-web3.sourceforge.net>

Bug #131204, was updated on 2001-Feb-05 18:35
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: fork()/execv() IDE Crash

Details: I'm just learning the fork()/execv() business and i'm sure this
code is crappy... but it does crash IDLE on Windows 98
#system test
import os
MyList = ['127.0.0.1']
while 1:
    
    os.execv('C:\Windows\ping', MyList )
    os.fork()


Follow-Ups:

Date: 2001-Feb-05 18:36
By: nobody

Comment:
Questions/Comments can be sent to radiohead83@yahoo.com
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131204&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 02:50:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Feb 2001 18:50:41 -0800
Subject: [Python-bugs-list] [Bug #131207] Fatal Python Error during program shutdown
Message-ID: <E14PyDJ-00030J-00@usw-sf-web3.sourceforge.net>

Bug #131207, was updated on 2001-Feb-05 18:50
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: djhender
Assigned to : nobody
Summary: Fatal Python Error during program shutdown

Details: 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.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131207&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 02:51:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Feb 2001 18:51:43 -0800
Subject: [Python-bugs-list] [Bug #131204] fork()/execv() IDE Crash
Message-ID: <E14PyEJ-0003HX-00@usw-sf-web1.sourceforge.net>

Bug #131204, was updated on 2001-Feb-05 18:35
Here is a current snapshot of the bug.

Project: Python
Category: IDLE
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Submitted by: nobody
Assigned to : effbot
Summary: fork()/execv() IDE Crash

Details: I'm just learning the fork()/execv() business and i'm sure this
code is crappy... but it does crash IDLE on Windows 98
#system test
import os
MyList = ['127.0.0.1']
while 1:
    
    os.execv('C:\Windows\ping', MyList )
    os.fork()


Follow-Ups:

Date: 2001-Feb-05 18:51
By: tim_one

Comment:
Assigned to effbot for pondering.  On Win98SE, the loop isn't needed, and
neither is the fork.  os.execv is enough to crash IDLE.  It dies in
tk83.dll.  If I do

bin = r'\bin\wc.exe'
os.execv(bin, [bin, bin])

then wc does run to completion, so I imagine Tk is mondo confused about
Python going away.

"Nobody", fork doesn't even exist on Windows:

>>> import os
>>> os.fork
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'os' module has no attribute 'fork'
>>>

This is stuff is natural only on Unix systems.  On Windows, play with the
os.spawn* functions instead.
-------------------------------------------------------

Date: 2001-Feb-05 18:36
By: nobody

Comment:
Questions/Comments can be sent to radiohead83@yahoo.com
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131204&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 05:13:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Feb 2001 21:13:07 -0800
Subject: [Python-bugs-list] [Bug #116289] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E14Q0R9-00045O-00@usw-sf-web1.sourceforge.net>

Bug #116289, was updated on 2000-Oct-06 19:25
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: 3rd Party
Priority: 3
Submitted by: tim_one
Assigned to : tim_one
Summary: Programs using Tkinter sometimes can't shut down (Windows)

Details: The following msg from the Tutor list is about 1.6, but I noticed
the same thing several times today using 2.0b2+CVS.  In my case, I was
running IDLE via

python ../tool/idle/idle.pyw

from a DOS box in my PCbuild directory.  Win98SE.  *Most* of the time,
shutting down IDLE via Ctrl+Q left the DOS box hanging.  As with the
poster, the only way to regain control was to use the Task Manager to kill
off Winoldap.

-----Original Message-----
From: Joseph Stubenrauch <nothingisgoingtochangemyworld@yahoo.com>
Sent: Friday, October 06, 2000 9:23 PM
To: tutor@python.org
Subject: Re: [Tutor] Python 1.6 BUG


Strange, I have been experiencing the same bug myself.
Here's the low down for me:

Python 1.6 with win95
I am running a little Tkinter program
The command line I use is simply: "python foo.py"
About 25-35% of the time, when I close the Tkinter
window, DOS seems to "freeze" and never returns to the
c:\ command prompt.  I have to ctrl-alt-delete
repeatedly and shut down "winoldapp" to get rid of the
window and then shell back into DOS and keep working.
It's a bit of a pain, since I have the habit of
testing EVERYTHING in tiny little stages, so I change
one little thing, test it ... freeze ... ARGH!  Change
one more tiny thing, test it ... freeze ... ARGH! 
However, sometimes it seems to behave and doesn't
bother me for an entire several hour session of python
work.

That's my report on the problem.

Cheers,

Joe


Follow-Ups:

Date: 2001-Feb-05 21:13
By: djhender

Comment:
This was a symptom I saw while tracking down the essence of the problem
reported in #131207.  Using Win98SE, I would get an error dialog (GPF?) in
the Kernel, and sometimes the dos prompt would not come back.
-------------------------------------------------------

Date: 2000-Dec-12 18:00
By: tim_one

Comment:
Just reproduced w/ current CVS, but didn't hang until the 8th try.

http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest
released version; don't know whether that URL still makes sense, though.
-------------------------------------------------------

Date: 2000-Dec-12 12:58
By: gvanrossum

Comment:
Tim, can you still reproduce this with the current CVS version?

There's been one critical patch to _tkinter since the 2.0 release.

An alternative would be to try with a newer version of Tcl (isn't 8.4 out
already?).

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

Date: 2000-Oct-15 09:47
By: nobody

Comment:
Same as I've reported earlier; it hangs in the call to
Tcl_Finalize (which is called by the DLL finalization
code).  It's less likely to hang if I call Tcl_Finalize
from the _tkinter DLL (from user code).

Note that the problem isn't really Python-related -- I
have stand-alone samples (based on wish) that hangs in
the same way.

More later.

</F>
-------------------------------------------------------

Date: 2000-Oct-13 07:40
By: gvanrossum

Comment:
Back to Tim since I have no clue what to do here.
-------------------------------------------------------

Date: 2000-Oct-12 10:25
By: gvanrossum

Comment:
The recent fix to _tkinter (Tcl_GetStringResult(interp) instead of
interp->result) didn't fix this either.

As Tim has remarked in private but not yet recorded here, a workaround is
to use pythonw instead of python, so I'm lowering thepriority again.

Also note that the hanging process that Tim writes about apparently
prevents Win98 from shutting down properly.
-------------------------------------------------------

Date: 2000-Oct-07 00:37
By: tim_one

Comment:
More info (none good, but some worse so boosted priority):

+ Happens under release and debug builds.

+ Have not been able to provoke when starting in the debugger.

+ Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up. 
There's still a Python (or Python_d) process hanging around that
Ctrl+Alt+Del doesn't show.

+ This process makes it impossible to delete the associated Python .dll,
and in particular makes it impossible to rebuild Python successfully
without a reboot.

+ These processes cannot be killed!  Wintop and Process Viewer both fail to
get the job done.  PrcView (a freeware process viewer) itself locks up if I
try to kill them using it.  Process Viewer freezes for several seconds
before giving up.

+ Attempting to attach to the process with the MSVC debugger (in order to
find out what the heck it's doing) finds the process OK, but then yields
the cryptic and undocumented error msg "Cannot execute program".

+ The processes are not accumulating cycles.

+ Smells like deadlock.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116289&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 05:30:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Feb 2001 21:30:09 -0800
Subject: [Python-bugs-list] [Bug #131207] Fatal Python Error during program shutdown
Message-ID: <E14Q0hd-0002p0-00@usw-sf-web2.sourceforge.net>

Bug #131207, was updated on 2001-Feb-05 18:50
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: djhender
Assigned to : nobody
Summary: Fatal Python Error during program shutdown

Details: 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.

Follow-Ups:

Date: 2001-Feb-05 21:30
By: djhender

Comment:
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.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131207&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 07:50:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 05 Feb 2001 23:50:49 -0800
Subject: [Python-bugs-list] [Bug #131222] Python-2.1a2: HP make continiously runs the configure script
Message-ID: <E14Q2tl-0004zP-00@usw-sf-web1.sourceforge.net>

Bug #131222, was updated on 2001-Feb-05 23:50
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: Python-2.1a2: HP make continiously runs the configure script

Details: Source:		Python-2.1a2
OS:		HP-UX 11.00

Commands:
	./configure  (or ./configure --with-threads=no)
	make

Details:
	Once make finishes compiling Python/dynload_hpux.c, it runs the configure
script, which will continue to run over and over.

.....
        gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include
-DHAVE_CONFIG_H -o Python/traceback.o Python/traceback.c
        gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include
-DHAVE_CONFIG_H -o Python/getopt.o Python/getopt.c
        gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include
-DHAVE_CONFIG_H -o Python/dynload_hpux.o Python/dynload_hpux.c
        if test -f config.status; \
        then /bin/sh config.status --recheck; \
             /bin/sh config.status; \
        else /bin/sh ./configure ; \
        fi
running /bin/sh ./configure  --prefix=/opt/python2 --with-threads=no
--no-create --no-recursion
loading cache ./config.cache
checking MACHDEP... hp-uxB
checking for --without-gcc... no
checking for --with-cxx=<compiler>... no
checking for c++... (cached) c++

....


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131222&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 08:25:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Feb 2001 00:25:56 -0800
Subject: [Python-bugs-list] [Bug #131225] sys.winver is still '2.0' in python 2.1a2
Message-ID: <E14Q3Rk-000591-00@usw-sf-web3.sourceforge.net>

Bug #131225, was updated on 2001-Feb-06 00:25
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: theller
Assigned to : nobody
Summary: sys.winver is still '2.0' in python 2.1a2

Details: sys.winver is still '2.0' in python 2.1a2 although the registry
entries are stored under 2.1a2.

(Also the version resources, displayed when rightclicked in explorer, look
a little strange, but I dont't really care).

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131225&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 10:10:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Feb 2001 02:10:26 -0800
Subject: [Python-bugs-list] [Bug #131235] mpzmodule wont compile with msvc
Message-ID: <E14Q54s-0005ok-00@usw-sf-web3.sourceforge.net>

Bug #131235, was updated on 2001-Feb-06 02:10
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 5
Submitted by: mpmak
Assigned to : nobody
Summary: mpzmodule wont compile with msvc

Details: 
Non const initializer in mpzmodule, around line 1587:
is:
PyObject_HEAD_INIT(&PyType_Type)
sholud be:
PyObject_HEAD_INIT(NULL)

and in module initialization:
MPZtype.ob_type = &PyType_Type;


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131235&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 10:17:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Feb 2001 02:17:46 -0800
Subject: [Python-bugs-list] [Bug #131237] multiple symbol definition - Py_DebugFlag
Message-ID: <E14Q5By-0005sG-00@usw-sf-web3.sourceforge.net>

Bug #131237, was updated on 2001-Feb-06 02:17
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: mpmak
Assigned to : nobody
Summary: multiple symbol definition - Py_DebugFlag

Details: 
Some modules have its own definition of varius python core variables. MSVC
will only compile them if storage class is the same
__declspec(dllexport).

firstsets.c, grammar.c, pgen.c : Py_DebugFlag and Py_VerboseFlag

pgenmain.c : Py_DebugFlags, Py_VerboseFlag, Py_FatalError,
PySys_WriteStderr


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131237&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 10:30:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Feb 2001 02:30:45 -0800
Subject: [Python-bugs-list] [Bug #131239] -x flag is ignored on non pyc files
Message-ID: <E14Q5OX-0005uZ-00@usw-sf-web1.sourceforge.net>

Bug #131239, was updated on 2001-Feb-06 02:30
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mpmak
Assigned to : nobody
Summary: -x flag is ignored on non pyc files

Details: 
simple script x.bat will raise syntax error in line 1
@python -x "%~f0" %* & goto :EOF
print 'ok'

maybe_pyc_file in pythonrun.c does not save/restore file position when
reading non pyc file which was given as argument on command line.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131239&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 12:59:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Feb 2001 04:59:22 -0800
Subject: [Python-bugs-list] [Bug #131249] cgi.py opens too many (temporary) files
Message-ID: <E14Q7iM-0006wm-00@usw-sf-web1.sourceforge.net>

Bug #131249, was updated on 2001-Feb-06 04:59
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: stadt
Assigned to : nobody
Summary: cgi.py opens too many (temporary) files

Details: cgi.FieldStorage() is used to get the contents of a webform. It
turns out that
for each <input> line, a new temporary file is opened. This causes the
script
that is using cgi.FieldStorage() to reach the webserver's limit of number
of
opened files, as described by 'ulimit -n'. The standard value for Solaris
systems
seems to be 64, so webforms with that many <input> fields cannot be dealt
with.

A solution would seem to use the same temporary filename, since only a
maxmimum one file is (temporarily) used at the same time. I did an "ls|wc
-l"
while the script was running, which showed only zeroes and ones.

(I'm using Python for CyberChair, an online paper submission and reviewing
system.
The webform under discussion has one input field for each reviewer, stating
the
papers he or she is supposed to be reviewing. One conference that is using
CyberChair
has almost 140 reviewers. Their system's open file limit is 64. Using the
same data on
a system with an open file limit of 260 _is_ able to deal with this.)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131249&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 16:43:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Feb 2001 08:43:13 -0800
Subject: [Python-bugs-list] [Bug #131273] [windows] os.popen doens't kill subprocess when interrupted
Message-ID: <E14QBCz-0008VJ-00@usw-sf-web1.sourceforge.net>

Bug #131273, was updated on 2001-Feb-06 08:43
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: cgouiran
Assigned to : nobody
Summary: [windows] os.popen doens't kill subprocess when interrupted

Details: Hi, in the following script I liked to make an interface to the
contig program(http://www.sysinternals.com)

As the popen invocation can be a long time process (since it walks
recursively trough directories) I press CTRL-C sometimes and the contig
continues to run.

I use Python 2.0 (BeOpen version) under WinNT 4.0(SP 4)

Maybe I made a mistake in the following script ?

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

#! /usr/bin/env python

import sys;
import os;
import re;

content = ""

mm = re.compile("Processing (.+)?:\nFragments: (\d+)?");

output = os.popen("contig -a -s *.*");

while(1):
  line = output.readline();
	
  if line == '':
    break
	
    content += line;


status = output.close()

if status:
  print("Error contig : "+`status`+"("+os.strerror(status)+")");
  sys.exit(12);

print mm.findall(content)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131273&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 17:18:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Feb 2001 09:18:16 -0800
Subject: [Python-bugs-list] [Bug #129995] segfaults on AIX if configured with threads
Message-ID: <E14QBku-0000bv-00@usw-sf-web3.sourceforge.net>

Bug #129995, was updated on 2001-Jan-24 16:44
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: bcollar
Assigned to : twouters
Summary: segfaults on AIX if configured with threads

Details: Hi. AIX 4.2.1. ran ./configure --without-gcc
--prefix=/development/utils. make CC=xlC OPT="-O2 -qmaxmem=4000". some of
the make output follows. Let me know if you need all of it.

if test ! -f ../Modules/hassignal;  then echo adding sigcheck.o; ar r
../libpython2.1.a sigcheck.o;  else echo leaving sigcheck.o out; fi
leaving sigcheck.o out
        touch add2lib
        if test -f hassignal;  then echo removing sigcheck.o intrcheck.o; 
ar d ../libpython2.1.a sigcheck.o intrcheck.o 2>/dev/null;  else echo
leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
make: 1254-004 The error code from the last command is 2.
make: 1254-005 Ignored error code 2 from last command.
        ar cr ../libpython2.1.a gcmodule.o  threadmodule.o  posixmodule.o 
_sre.o  signalmodule.o config.o getpath.o main.o getbuildinfo.o
        touch add2lib
        cd Modules; make OPT="-O2 -qmaxmem=4000" python.o
        xlC -O2 -qmaxmem=4000 -I./../Include -I.. -DHAVE_CONFIG_H -c
python.c
        expr `cat buildno` + 1 >buildno1
        mv -f buildno1 buildno
        xlC -c -O2 -qmaxmem=4000 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno` 
./Modules/getbuildinfo.c
        ar cr libpython2.1.a getbuildinfo.o
        ranlib libpython2.1.a
        true
        cd Modules;  make OPT="-O2 -qmaxmem=4000" VERSION="2.1" 
prefix="/development/utils/" exec_prefix="/development/utils/" 
LIBRARY=../libpython2.1.a link
        ./makexp_aix python.exp "" ../libpython2.1.a;  xlC 
-Wl,-bE:python.exp -lld python.o  ../libpython2.1.a   -ldl  -lpthreads -lm 
-o python 
        mv python ../python
        ./python ./setup.py build
pthread_mutex_init: Error 0
pthread_cond_init: Error 0
pthread_mutex_lock[1]: Error 0
make: 1254-059 The signal code from the last command is 11.


Follow-Ups:

Date: 2001-Feb-06 09:18
By: donnc

Comment:
Instead of xlC,  use cc_r.  That (on my host anyway) is
the xlC.cfg compiler configuration that uses the reentrant
libraries for thread support, which are not the default.
-------------------------------------------------------

Date: 2001-Feb-02 05:59
By: twouters

Comment:
I'd like to note that though I don't have access to AIX myself, I do live
with and share a bed with a system administrator who does, very much so,
many, many hours per week. She doesn't have a *compiler* on AIX, though, so
more than general AIX info and the odd programmers manual is out of the
question.

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

Date: 2001-Feb-01 09:21
By: bwarsaw

Comment:
Assigning this to Thomas, since I don't have an AIX machine handy, and he
made the mistake of chiming in. :)
-------------------------------------------------------

Date: 2001-Feb-01 06:53
By: twouters

Comment:
Try making sure configure itself is also run with the same CC and OPT
arguments, by running configure like this (using (ba)sh syntax, should work
in ksh as well):

CC=xlC CFLAGS="-O2 -qmaxmem=4000" ./configure <normalopts>

configure might be mis-detecting some things because of the different
arguments.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129995&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 18:33:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Feb 2001 10:33:34 -0800
Subject: [Python-bugs-list] [Bug #131304] a few misprints in 2.0 Python/C  API manual
Message-ID: <E14QCvm-0008QU-00@usw-sf-web2.sourceforge.net>

Bug #131304, was updated on 2001-Feb-06 10:33
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: a few misprints in 2.0 Python/C  API manual

Details: In section 7.2.4, Tuple Objects, various
functions, such as PyTuple_Size, PyTuple_GetItem,
PyTuple_GetSlice are listed as taking a PyTupleObject *.
In tupleobject.h they are declared to take PyObject *.
This just causes some warnings I guess.

Also  I see that _PyTuple_Resize is listed as taking a PyTupleObject
*,while in tupleobject.h it is declared to take PyObject **.  I haven't
tried this function but
I suppose this is a more significant difference.

... Since I'm not an expert and just getting started writing an extension I
hope I'm not wasting your time with these.

cheers,
John
John R. Baxter
baxter@math.umn.edu

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131304&group_id=5470


From noreply@sourceforge.net  Tue Feb  6 21:28:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 06 Feb 2001 13:28:53 -0800
Subject: [Python-bugs-list] [Bug #131328] fcntl module functions should accept file module arguments.
Message-ID: <E14QFfR-0002Nf-00@usw-sf-web1.sourceforge.net>

Bug #131328, was updated on 2001-Feb-06 13:28
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Submitted by: esr
Assigned to : nobody
Summary: fcntl module functions should accept file module arguments.

Details: 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.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131328&group_id=5470


From bcollar@cs.unm.edu  Wed Feb  7 02:43:24 2001
From: bcollar@cs.unm.edu (Benjamin Collar)
Date: Tue, 6 Feb 2001 19:43:24 -0700 (MST)
Subject: [Python-bugs-list] Re: [Bug #129995] segfaults on AIX if configured with threads
In-Reply-To: <E14QBku-0000bv-00@usw-sf-web3.sourceforge.net>
Message-ID: <Pine.LNX.4.21.0102061942390.6995-100000@jah.cs.unm.edu>

current cvs tarball won't build because:

        ./makexp_aix python.exp "" libpython2.1.a;  cc_r
-Wl,-bE:python.exp -lld -o python Modules/python.o  libpython2.1.a -ldl
-lm  
/bin/sh: ./makexp_aix:  not found.
make: 1254-004 The error code from the last command is 127.

this is on AIX 4.2.1.

Ben



From noreply@sourceforge.net  Wed Feb  7 09:56:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Feb 2001 01:56:31 -0800
Subject: [Python-bugs-list] [Bug #131377] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E14QRKx-0006C7-00@usw-sf-web2.sourceforge.net>

Bug #131377, was updated on 2001-Feb-07 01:56
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: twallgram
Assigned to : nobody
Summary: [HP-UX] Python chokes on pthread_mutex_init

Details: Hello,
I need python 1.5.2 (only this version) on a HP-UX-System with threads. I
started configure with the --with-threads-Option. Then I did the
'make'-command (No problems during the compilation). Then I started make
test. See the output bellow:

# make test
        (cd Modules; make -f Makefile.pre Makefile)
`Makefile' is up to date.
making Makefile in subdirectory .
`Makefile' is up to date.
making Makefile in subdirectory Parser
`Makefile' is up to date.
making Makefile in subdirectory Objects
`Makefile' is up to date.
making Makefile in subdirectory Python
`Makefile' is up to date.
making Makefile in subdirectory Modules
        (rm -f Modules/hassignal; cd Modules; make hassignal)
        rm -f hassignal
        for i in threadmodule.o  regexmodule.o regexpr.o  pcremodule.o
pypcre.o  posixmodule.o  signalmodule.o  arraymodule.o  cmathmodule.o 
mathmodule.o  stropmodule.o  structmodule.o  timemodule.o  operator.o 
fcntlmodule.o  pwdmodule.o  grpmodule.o  selectmodule.o  socketmodule.o 
errnomodule.o  md5module.o md5c.o  shamodule.o  rotormodule.o  newmodule.o 
binascii.o  parsermodule.o  cStringIO.o  cPickle.o config.o getpath.o
main.o getbuildinfo.o; do \
                    if test "$i" = "signalmodule.o"; then \
                       echo yes >hassignal; break; \
                    fi; \
                done
        cd Parser ; make OPT="-g -O2" VERSION="1.5" \
                        prefix="/usr/local" exec_prefix="/usr/local" all
        cd Objects ; make OPT="-g -O2" VERSION="1.5" \
                        prefix="/usr/local" exec_prefix="/usr/local" all
        cd Python ; make OPT="-g -O2" VERSION="1.5" \
                        prefix="/usr/local" exec_prefix="/usr/local" all
        cd Modules ; make OPT="-g -O2" VERSION="1.5" \
                        prefix="/usr/local" exec_prefix="/usr/local" all
        if test ! -f libpython1.5.a; \
                then for i in Parser Objects Python Modules; do rm -f
$i/add2lib; done; true; \
                else true; fi
        for i in Parser Objects Python Modules; do \
                        (cd $i; make VERSION="1.5" add2lib); done
`add2lib' is up to date.
`add2lib' is up to date.
`add2lib' is up to date.
`add2lib' is up to date.
        rm -f ./Lib/test/*.py[co]
        PYTHONPATH= ./python ./Lib/test/regrtest.py 
pthread_mutex_init: Invalid argument
sh: 11423 Memory fault(coredump)
*** Error exit code 139 (ignored)
        PYTHONPATH= ./python ./Lib/test/regrtest.py 
pthread_mutex_init: Invalid argument
sh: 11425 Memory fault(coredump)
*** Error exit code 139

Stop.

I need python 1.5.2 for compiling Zope 2.0 (which only needs python in this
version with threads). It seems the same error as bug # 130029, but I can
submit a coredump. Can anybody help me? You can use this HP-UX-machine for
checking the compilation :-) 

bye Tom


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131377&group_id=5470


From mal@lemburg.com  Wed Feb  7 12:02:29 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Wed, 07 Feb 2001 13:02:29 +0100
Subject: [Python-bugs-list] Re: [Bug #129995] segfaults on AIX if configured
 with threads
References: <Pine.LNX.4.21.0102061942390.6995-100000@jah.cs.unm.edu>
Message-ID: <3A813955.14DEB0A7@lemburg.com>

Benjamin Collar wrote:
> 
> current cvs tarball won't build because:
> 
>         ./makexp_aix python.exp "" libpython2.1.a;  cc_r
> -Wl,-bE:python.exp -lld -o python Modules/python.o  libpython2.1.a -ldl
> -lm
> /bin/sh: ./makexp_aix:  not found.
> make: 1254-004 The error code from the last command is 127.
> 
> this is on AIX 4.2.1.

Could you tell us more about the context ? This seems to have
something to do with the following line in configure:

configure:
--         LINKCC="\$(srcdir)/makexp_aix python.exp \"\" \$(LIBRARY); \$(PURIFY) \$(CC)";;

AFAIK, makexp_aix lives in Modules/ so perhaps adding Modules/
will help ?!

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From noreply@sourceforge.net  Wed Feb  7 13:29:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Feb 2001 05:29:00 -0800
Subject: [Python-bugs-list] [Bug #131398] installation of Numeric for Python 2.0. is impossible
Message-ID: <E14QUea-0007Z2-00@usw-sf-web2.sourceforge.net>

Bug #131398, was updated on 2001-Feb-07 05:28
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: installation of Numeric for Python 2.0. is impossible

Details: Hello, everyone.

I have troubles with installing Numeric for Python 2.0.
After I download file Numeric-17.0.tar to directory Python20 and decompress
it there,
I run:

D:\Python20\Numeric-17.3.0>python setup.py install
running install
running build
running build_py
not copying Lib\ArrayPrinter.py (output up-to-date)
not copying Lib\Numeric.py (output up-to-date)
not copying Lib\numeric_version.py (output up-to-date)
not copying Lib\Precision.py (output up-to-date)
not copying Lib\UserArray.py (output up-to-date)
running build_ext
skipping '_numpy' extension (up-to-date)
skipping 'multiarray' extension (up-to-date)
building 'umath' extension
skipping Src/umathmodule.c
(build\temp.win32-2.0\Release\Src/umathmodule.obj up-
to-date)
D:\Program Files\Microsoft Visual Studio\VC98\BIN\link.exe /DLL /nologo
/INCREME
NTAL:NO /LIBPATH:D:\python20\libs m.lib /EXPORT:initumath
build\temp.win32-2.0\R
elease\Src/umathmodule.obj /OUT:build\lib.win32-2.0\umath.pyd
/IMPLIB:build\temp
.win32-2.0\Release\Src\umath.lib
LINK : fatal error LNK1181: cannot open input file "m.lib"
error: command '"D:\Program Files\Microsoft Visual
Studio\VC98\BIN\link.exe"' failed with exit status 1181

I would like that somebody would let me know when it is fixed.
And if possible, I would like to know about your plans conserning bug
#122395

my E-mail is: sveta@camelot.com
-------------------------------

Thank you,
Just one more thing:
I also tried several times to get registered here in order to be informed
about bugs, but for unknown reason it never works.
That's what I get after I enter all details needed for making a new
account:

The page cannot be displayed 
The page you are looking for is currently unavailable. The Web site might
be experiencing technical difficulties, or you may need to adjust your
browser settings. 

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

Please try the following:

Click the  Refresh button, or try again later.

"
If you typed the page address in the Address bar, make sure that it is
spelled correctly.

To check your connection settings, click the Tools menu, and then click
Internet Options. On the Connections tab, click Settings. The settings
should match those provided by your local area network (LAN) administrator
or Internet service provider (ISP). 
If your Network Administrator has enabled it, Microsoft Windows can examine
your network and automatically discover network connection settings.
If you would like Windows to try and discover them, 
click  Detect Network Settings 
Some sites require 128-bit connection security. Click the Help menu and
then click About Internet Explorer to determine what strength security you
have installed. 
If you are trying to reach a secure site, make sure your Security settings
can support it. Click the Tools menu, and then click Internet Options. On
the Advanced tab, scroll to the Security section and check settings for SSL
2.0, SSL 3.0, TLS 1.0, PCT 1.0. 
Click the  Back button to try another link. 

Cannot find server or DNS Error
Internet Explorer  
"

Why is that???

Thank you,
Svetlana.

my E-mail is: sveta@camelot.com
-------------------------------



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131398&group_id=5470


From noreply@sourceforge.net  Wed Feb  7 18:52:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Feb 2001 10:52:50 -0800
Subject: [Python-bugs-list] [Bug #131439] python and Python interfaces should use cc -G for so's
Message-ID: <E14QZhy-0001Y3-00@usw-sf-web2.sourceforge.net>

Bug #131439, was updated on 2001-Feb-07 10:52
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: ler
Assigned to : nobody
Summary: python and Python interfaces should use cc -G for so's

Details: the Python build environment should use cc -G for it's shared
libs.  This is true at *LEAST* on UnixWare.  The ld man page calls this
out. 

The PostgreSQL interface build had to be modified because of this. 

If you need a shell account on a UnixWare 7 box, I can arrange same. 

LER


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131439&group_id=5470


From noreply@sourceforge.net  Wed Feb  7 19:36:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Feb 2001 11:36:56 -0800
Subject: [Python-bugs-list] [Bug #131442] testing bug submission
Message-ID: <E14QaOe-0001t5-00@usw-sf-web2.sourceforge.net>

Bug #131442, was updated on 2001-Feb-07 11:36
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: testing bug submission

Details: is this still broken?

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131442&group_id=5470


From noreply@sourceforge.net  Wed Feb  7 20:32:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Feb 2001 12:32:42 -0800
Subject: [Python-bugs-list] [Bug #131442] testing bug submission
Message-ID: <E14QbGc-0002Zu-00@usw-sf-web1.sourceforge.net>

Bug #131442, was updated on 2001-Feb-07 11:36
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Invalid
Bug Group: Trash
Priority: 5
Submitted by: nobody
Assigned to : gvanrossum
Summary: testing bug submission

Details: is this still broken?

Follow-Ups:

Date: 2001-Feb-07 12:32
By: gvanrossum

Comment:
Yes it works.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131442&group_id=5470


From noreply@sourceforge.net  Wed Feb  7 22:37:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Feb 2001 14:37:43 -0800
Subject: [Python-bugs-list] [Bug #130165] Python 2.1a1 Makefile changed OPT value not used in module c
Message-ID: <E14QdDb-0004MF-00@usw-sf-web3.sourceforge.net>

Bug #130165, was updated on 2001-Jan-26 06:46
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : akuchling
Summary: Python 2.1a1 Makefile changed OPT value not used in module c

Details: When the top level "Makefile" value used for the variable "OPT" is
changed
after executing "configure", that new value is used to compile "python",
but is *not* used during the compilation of the modules.


Follow-Ups:

Date: 2001-Feb-07 14:37
By: akuchling

Comment:
Yes, but in 2.1alpha2 nothing should be doing 'cd Modules' at all, which is
why I'd like to know if it happens with either alpha2 or the current CVS
tree.

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

Date: 2001-Jan-30 00:47
By: nobody

Comment:
Updated more details by original submitter:

The problem appears shortly after a "cd Modules" but shows up only
during compilation of the ".so" extension modules.  The first module
compilation in the original 2.1a1 version to show the failure to use the
changed value of "OPT" follows the line:

	"building 'regex' extension"

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

Date: 2001-Jan-28 19:19
By: nobody

Comment:
I can't replicate this; when I edit the Makefile, the new OPT setting
is picked up by the setup script.  Does it still happen with the current
CVS version?
-------------------------------------------------------

Date: 2001-Jan-26 07:45
By: nascheme

Comment:
Hmm, perhaps the makefile could pass OPT to the distutils
setup.py script.  Andrew knows better than I how to solve
this.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130165&group_id=5470


From noreply@sourceforge.net  Wed Feb  7 23:07:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Feb 2001 15:07:40 -0800
Subject: [Python-bugs-list] [Bug #131170] make install fails on macosx for Python-2.1a2
Message-ID: <E14Qdga-0003SQ-00@usw-sf-web2.sourceforge.net>

Bug #131170, was updated on 2001-Feb-05 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: sdm7g
Assigned to : nobody
Summary: make install fails on macosx for Python-2.1a2

Details: Python-2.1a2 on macosx 
make install fails trying to ranlib the shared library:

ranlib: file: /usr/local/lib/python2.1/config/libpython2.1.dylib is not an
archive

(This bug wasn't in 2.0, and I don't think was in 2.1a1.)

-- Steve M.

Follow-Ups:

Date: 2001-Feb-07 15:07
By: sdm7g

Comment:
Note: after removing the ranlib, installation succeeds, and the program
works when you are in
the python directory, however, running the installed program from somewhere
else gives the 
fatal error:

dyld: python2.1 can't open library: libpython2.1.dylib  (No such file or
directory, errno = 2)

If you look at the python executable with 
"otool -L" , you can see that system frameworks,
for example, have their complete pathnames, while
libpython2.1.dylib has no path, so it's expected 
in the current directory. 

(looking for the libtool option to correct this...)  -- Steve M. 
-------------------------------------------------------

Date: 2001-Feb-05 13:12
By: nobody

Comment:
Commenting out the $(RANLIB) line in the
install section of Makefile seems to fix the problem on macosx, but I don't
know if it is a problemon any other platforms. 

       @if test -d $(LDLIBRARY); then :; else \
                $(INSTALL_DATA) $(LDLIBRARY) $(LIBPL)/$(LDLIBRARY) ; \
#               $(RANLIB) $(LIBPL)/$(LDLIBRARY) ; \

-- Steve M.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131170&group_id=5470


From bcollar@cs.unm.edu  Wed Feb  7 23:26:18 2001
From: bcollar@cs.unm.edu (Benjamin Collar)
Date: Wed, 7 Feb 2001 16:26:18 -0700 (MST)
Subject: [Python-bugs-list] Re: [Bug #129995] segfaults on AIX if configured  with threads, Re:
 Bug #129991
In-Reply-To: <3A813955.14DEB0A7@lemburg.com>
Message-ID: <Pine.LNX.4.21.0102071550140.19940-100000@jah.cs.unm.edu>

On Wed, 7 Feb 2001, M.-A. Lemburg wrote:

> > current cvs tarball won't build because:
> > 
> >         ./makexp_aix python.exp "" libpython2.1.a;  cc_r
> > -Wl,-bE:python.exp -lld -o python Modules/python.o  libpython2.1.a -ldl
> > -lm
> > /bin/sh: ./makexp_aix:  not found.
> > make: 1254-004 The error code from the last command is 127.
> > 
> > this is on AIX 4.2.1.
> 
> Could you tell us more about the context ? This seems to have
> something to do with the following line in configure:
> 
> configure:
> --         LINKCC="\$(srcdir)/makexp_aix python.exp \"\" \$(LIBRARY); \$(PURIFY) \$(CC)";;
> 
> AFAIK, makexp_aix lives in Modules/ so perhaps adding Modules/
> will help ?!

makexp_aix is in Modules. I've changed the above line to
LINKCC="\$(srcdir)/Modules/makexp_aix python.exp
\"\" \$(LIBRARY); \$(PURIFY) \$(CC)";;

This worked fine and now it compiles. Regarding the context, configure and
make were as follows:

CC=cc_r CFLAGS="-O2 -qmaxmem=5000" ./configure --without-gcc
--prefix=/development/utils

make CC=cc_r OPT="-O2 -qmaxmem=5000"

Regarding the segfault bug (Bug #129995), now that I've used cc_r there is
no segfault. Hooray! If I may make a suggestion, the note to use cc_r
should be put into the AIX documentation (especially since with-threads is
default).

BUT there are other problems still. None of the extensions built. This was
noted in Bug #129991: ld_so_aix is referenced before it exists. Here is a
sample error (all extensions error the same way):

building 'nis' extension
cc_r -I. -I/tmp/python/dist/src/./Include -IInclude/ -I/usr/local/include
-c /tmp/python/dist/src/Modules/nismodule.c -o
build/temp.aix-2-000310094C00-2.1/nismodule.o
/development/utils/lib/python2.1/config/ld_so_aix cc
-bI:/development/utils/lib/python2.1/config/python.exp
build/temp.aix-2-000310094C00-2.1/nismodule.o -L/usr/local/lib -lnsl -o
build/lib.aix-2-000310094C00-2.1/nis.so
unable to execute /development/utils/lib/python2.1/config/ld_so_aix: No
such file or directory
WARNING: building of extension "nis" failed: command
'/development/utils/lib/python2.1/config/ld_so_aix' failed with exit
status 1

ls /development/utils/lib:
libefence.a  libswig.a    python1.6    swig_lib

Ben



From noreply@sourceforge.net  Thu Feb  8 02:44:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Feb 2001 18:44:32 -0800
Subject: [Python-bugs-list] [Bug #131480] __test__() should auto-exec at compile time
Message-ID: <E14Qh4S-0004sm-00@usw-sf-web1.sourceforge.net>

Bug #131480, was updated on 2001-Feb-07 18:44
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: justinshaw
Assigned to : nobody
Summary: __test__() should auto-exec at compile time

Details: We can make unit testing as simple as writing the test code!
Everyone agrees that unit tests are worth while.  Python does a great job
removing tedium from the job of the programmer.  Unit test should run
automatically.  Here's a method everyone can agree to:

Have the compiler check each module for a funtion with the special name
'__test__' that takes no arguments.  If it finds it it calls it.

The problem of unit testing divides esiliy into two pieces: How to create
the code and how to execute the code.  There are many options in creating
the code but I have never seen any nice solutions to run the code
automatically
"if __name__ == '__main__':"
 doesn't count since you have to do somthing special to call the code i.e.
run it as a script.  There are of course ways to run the test code
automatically but the ways I have figured out run it on every import (way
too often especially for long tests).  I imagine there is a way to check to
see if the module is loaded from a .pyc file and execute test code
accouringly but this seems a bit kludgy.  Here are the benifits of compile
time auto-execution:

- Compatible with every testing framework.
- Called always and only when it needs to be executed.
- So simple even micro projects 'scripts' can take advantage

Disadvantages:
- Another special name, '__test__'
- If there are more please tell me!

I looked around the source-code and think I see the location where we can
do this.  It's would be a piece of cake and the advantages far outway the
disadvantages.  If I get some support I'd love to incorporate the fix.

Justin Shaw
thomas.j.shaw@aero.org

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131480&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 03:34:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Feb 2001 19:34:27 -0800
Subject: [Python-bugs-list] [Bug #131170] make install fails on macosx for Python-2.1a2
Message-ID: <E14Qhql-0005BJ-00@usw-sf-web1.sourceforge.net>

Bug #131170, was updated on 2001-Feb-05 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: sdm7g
Assigned to : nobody
Summary: make install fails on macosx for Python-2.1a2

Details: Python-2.1a2 on macosx 
make install fails trying to ranlib the shared library:

ranlib: file: /usr/local/lib/python2.1/config/libpython2.1.dylib is not an
archive

(This bug wasn't in 2.0, and I don't think was in 2.1a1.)

-- Steve M.

Follow-Ups:

Date: 2001-Feb-07 19:34
By: sdm7g

Comment:
Well, the missing libtool switch to tell it the
library will be installed somewhere else is:

 -install_name  $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to
be unable to find the os.module and sys.path
is set all  wrong. (and it fails somewhere 
else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK
conditional code in getpath.c is getting
the path not from the executable, but from
the library. 

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

Date: 2001-Feb-07 15:07
By: sdm7g

Comment:
Note: after removing the ranlib, installation succeeds, and the program
works when you are in
the python directory, however, running the installed program from somewhere
else gives the 
fatal error:

dyld: python2.1 can't open library: libpython2.1.dylib  (No such file or
directory, errno = 2)

If you look at the python executable with 
"otool -L" , you can see that system frameworks,
for example, have their complete pathnames, while
libpython2.1.dylib has no path, so it's expected 
in the current directory. 

(looking for the libtool option to correct this...)  -- Steve M. 
-------------------------------------------------------

Date: 2001-Feb-05 13:12
By: nobody

Comment:
Commenting out the $(RANLIB) line in the
install section of Makefile seems to fix the problem on macosx, but I don't
know if it is a problemon any other platforms. 

       @if test -d $(LDLIBRARY); then :; else \
                $(INSTALL_DATA) $(LDLIBRARY) $(LIBPL)/$(LDLIBRARY) ; \
#               $(RANLIB) $(LIBPL)/$(LDLIBRARY) ; \

-- Steve M.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131170&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 03:42:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Feb 2001 19:42:31 -0800
Subject: [Python-bugs-list] [Bug #131170] make install fails on macosx for Python-2.1a2
Message-ID: <E14QhyZ-0005EG-00@usw-sf-web1.sourceforge.net>

Bug #131170, was updated on 2001-Feb-05 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: sdm7g
Assigned to : nobody
Summary: make install fails on macosx for Python-2.1a2

Details: Python-2.1a2 on macosx 
make install fails trying to ranlib the shared library:

ranlib: file: /usr/local/lib/python2.1/config/libpython2.1.dylib is not an
archive

(This bug wasn't in 2.0, and I don't think was in 2.1a1.)

-- Steve M.

Follow-Ups:

Date: 2001-Feb-07 19:42
By: sdm7g

Comment:
Well, the missing libtool switch to tell it the
library will be installed somewhere else is:

 -install_name  $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to
be unable to find the os.module and sys.path
is set all  wrong. (and it fails somewhere 
else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK
conditional code in getpath.c is getting
the path not from the executable, but from
the library. 

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

Date: 2001-Feb-07 19:34
By: sdm7g

Comment:
Well, the missing libtool switch to tell it the
library will be installed somewhere else is:

 -install_name  $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to
be unable to find the os.module and sys.path
is set all  wrong. (and it fails somewhere 
else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK
conditional code in getpath.c is getting
the path not from the executable, but from
the library. 

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

Date: 2001-Feb-07 15:07
By: sdm7g

Comment:
Note: after removing the ranlib, installation succeeds, and the program
works when you are in
the python directory, however, running the installed program from somewhere
else gives the 
fatal error:

dyld: python2.1 can't open library: libpython2.1.dylib  (No such file or
directory, errno = 2)

If you look at the python executable with 
"otool -L" , you can see that system frameworks,
for example, have their complete pathnames, while
libpython2.1.dylib has no path, so it's expected 
in the current directory. 

(looking for the libtool option to correct this...)  -- Steve M. 
-------------------------------------------------------

Date: 2001-Feb-05 13:12
By: nobody

Comment:
Commenting out the $(RANLIB) line in the
install section of Makefile seems to fix the problem on macosx, but I don't
know if it is a problemon any other platforms. 

       @if test -d $(LDLIBRARY); then :; else \
                $(INSTALL_DATA) $(LDLIBRARY) $(LIBPL)/$(LDLIBRARY) ; \
#               $(RANLIB) $(LIBPL)/$(LDLIBRARY) ; \

-- Steve M.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131170&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 03:43:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 07 Feb 2001 19:43:05 -0800
Subject: [Python-bugs-list] [Bug #131170] make install fails on macosx for Python-2.1a2
Message-ID: <E14Qhz7-0005EY-00@usw-sf-web1.sourceforge.net>

Bug #131170, was updated on 2001-Feb-05 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: sdm7g
Assigned to : nobody
Summary: make install fails on macosx for Python-2.1a2

Details: Python-2.1a2 on macosx 
make install fails trying to ranlib the shared library:

ranlib: file: /usr/local/lib/python2.1/config/libpython2.1.dylib is not an
archive

(This bug wasn't in 2.0, and I don't think was in 2.1a1.)

-- Steve M.

Follow-Ups:

Date: 2001-Feb-07 19:43
By: sdm7g

Comment:
Well, the missing libtool switch to tell it the
library will be installed somewhere else is:

 -install_name  $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to
be unable to find the os.module and sys.path
is set all  wrong. (and it fails somewhere 
else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK
conditional code in getpath.c is getting
the path not from the executable, but from
the library. 

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

Date: 2001-Feb-07 19:42
By: sdm7g

Comment:
Well, the missing libtool switch to tell it the
library will be installed somewhere else is:

 -install_name  $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to
be unable to find the os.module and sys.path
is set all  wrong. (and it fails somewhere 
else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK
conditional code in getpath.c is getting
the path not from the executable, but from
the library. 

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

Date: 2001-Feb-07 19:34
By: sdm7g

Comment:
Well, the missing libtool switch to tell it the
library will be installed somewhere else is:

 -install_name  $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to
be unable to find the os.module and sys.path
is set all  wrong. (and it fails somewhere 
else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK
conditional code in getpath.c is getting
the path not from the executable, but from
the library. 

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

Date: 2001-Feb-07 15:07
By: sdm7g

Comment:
Note: after removing the ranlib, installation succeeds, and the program
works when you are in
the python directory, however, running the installed program from somewhere
else gives the 
fatal error:

dyld: python2.1 can't open library: libpython2.1.dylib  (No such file or
directory, errno = 2)

If you look at the python executable with 
"otool -L" , you can see that system frameworks,
for example, have their complete pathnames, while
libpython2.1.dylib has no path, so it's expected 
in the current directory. 

(looking for the libtool option to correct this...)  -- Steve M. 
-------------------------------------------------------

Date: 2001-Feb-05 13:12
By: nobody

Comment:
Commenting out the $(RANLIB) line in the
install section of Makefile seems to fix the problem on macosx, but I don't
know if it is a problemon any other platforms. 

       @if test -d $(LDLIBRARY); then :; else \
                $(INSTALL_DATA) $(LDLIBRARY) $(LIBPL)/$(LDLIBRARY) ; \
#               $(RANLIB) $(LIBPL)/$(LDLIBRARY) ; \

-- Steve M.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131170&group_id=5470


From mal@lemburg.com  Thu Feb  8 12:48:20 2001
From: mal@lemburg.com (M.-A. Lemburg)
Date: Thu, 08 Feb 2001 13:48:20 +0100
Subject: [Python-bugs-list] AIX build problems (Re: [Bug #129995] segfaults
 on AIX if configured  with threads, Re:Bug #129991)
References: <Pine.LNX.4.21.0102071550140.19940-100000@jah.cs.unm.edu>
Message-ID: <3A829594.37A688B4@lemburg.com>

Benjamin Collar wrote:
> 
> On Wed, 7 Feb 2001, M.-A. Lemburg wrote:
> 
> > > current cvs tarball won't build because:
> > >
> > >         ./makexp_aix python.exp "" libpython2.1.a;  cc_r
> > > -Wl,-bE:python.exp -lld -o python Modules/python.o  libpython2.1.a -ldl
> > > -lm
> > > /bin/sh: ./makexp_aix:  not found.
> > > make: 1254-004 The error code from the last command is 127.
> > >
> > > this is on AIX 4.2.1.
> >
> > Could you tell us more about the context ? This seems to have
> > something to do with the following line in configure:
> >
> > configure:
> > --         LINKCC="\$(srcdir)/makexp_aix python.exp \"\" \$(LIBRARY); \$(PURIFY) \$(CC)";;
> >
> > AFAIK, makexp_aix lives in Modules/ so perhaps adding Modules/
> > will help ?!
> 
> makexp_aix is in Modules. I've changed the above line to
> LINKCC="\$(srcdir)/Modules/makexp_aix python.exp
> \"\" \$(LIBRARY); \$(PURIFY) \$(CC)";;
> 
> This worked fine and now it compiles. Regarding the context, configure and
> make were as follows:
> 
> CC=cc_r CFLAGS="-O2 -qmaxmem=5000" ./configure --without-gcc
> --prefix=/development/utils
> 
> make CC=cc_r OPT="-O2 -qmaxmem=5000"
> 
> Regarding the segfault bug (Bug #129995), now that I've used cc_r there is
> no segfault. Hooray! If I may make a suggestion, the note to use cc_r
> should be put into the AIX documentation (especially since with-threads is
> default).

Could you submit a patch for these changes (configure.in and
Misc/AIX-NOTES), so that we can get them into 2.1 ? Thanks.

Perhaps there's also a way to have configure.in use the cc_r
compiler when building with threads ?!

> BUT there are other problems still. None of the extensions built. This was
> noted in Bug #129991: ld_so_aix is referenced before it exists. Here is a
> sample error (all extensions error the same way):
> 
> building 'nis' extension
> cc_r -I. -I/tmp/python/dist/src/./Include -IInclude/ -I/usr/local/include
> -c /tmp/python/dist/src/Modules/nismodule.c -o
> build/temp.aix-2-000310094C00-2.1/nismodule.o
> /development/utils/lib/python2.1/config/ld_so_aix cc
> -bI:/development/utils/lib/python2.1/config/python.exp
> build/temp.aix-2-000310094C00-2.1/nismodule.o -L/usr/local/lib -lnsl -o
> build/lib.aix-2-000310094C00-2.1/nis.so
> unable to execute /development/utils/lib/python2.1/config/ld_so_aix: No
> such file or directory
> WARNING: building of extension "nis" failed: command
> '/development/utils/lib/python2.1/config/ld_so_aix' failed with exit
> status 1
> 
> ls /development/utils/lib:
> libefence.a  libswig.a    python1.6    swig_lib

ld_so_aix lives in Modules/ too (and is not built from another
source). Looking at the above shell lines, it seems that ld_so_aix
is not installed properly before running setup.py.

Could you check whether these two utilities are in fact installed
in lib/python2.1/config/ ?

To fix the ld_so_aix problem, you will have to insert a Modules/
in the configure.in line as well:

        case $ac_sys_system/$ac_sys_release in
        AIX*) LDSHARED="\$(srcdir)/ld_so_aix \$(CC)";;

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/


From noreply@sourceforge.net  Thu Feb  8 13:12:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 05:12:56 -0800
Subject: [Python-bugs-list] [Bug #131225] sys.winver is still '2.0' in python 2.1a2
Message-ID: <E14Qqsa-00005h-00@usw-sf-web1.sourceforge.net>

Bug #131225, was updated on 2001-Feb-06 00:25
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: theller
Assigned to : nobody
Summary: sys.winver is still '2.0' in python 2.1a2

Details: sys.winver is still '2.0' in python 2.1a2 although the registry
entries are stored under 2.1a2.

(Also the version resources, displayed when rightclicked in explorer, look
a little strange, but I dont't really care).

Follow-Ups:

Date: 2001-Feb-08 05:12
By: lhudson

Comment:
This is bit of a nasty one as it causes pywintypes20.dll and
pythoncom20.dll to be loaded instead of the 21 versions
(PyWin_FindRegisteredModule behaviour).

Patch #103683 fixes this problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131225&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 15:53:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 07:53:44 -0800
Subject: [Python-bugs-list] [Bug #131540] threads and profiler don't work together
Message-ID: <E14QtOC-0001CL-00@usw-sf-web1.sourceforge.net>

Bug #131540, was updated on 2001-Feb-08 07:53
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: dbrueck
Assigned to : nobody
Summary: threads and profiler don't work together

Details: When a new thread is created, it doesn't inherit from the parent
thread the trace and profile functions (sys_tracefunc and sys_profilefunc
in PyThreadState), so multithreaded programs can't easily be profiled. 

This may be by design for safety/complexity sake, but the profiler module
should still find some way to function correctly. A temporary (and
performance-killing) workaround is to modify the standard profiler to hook
into threads to start a new profiler for each new thread, and then merge
the stats from a child thread into the parent's when the child thread
ends.

Here is sample code that exhibits the problem. Stats are printed only for
the main thread because the child thread has no profiling function and
therefore collects no stats:

import threading, profile, time

def yo():
    for j in range(5):
        print j,

def go():
    threading.Thread(target=yo).start()
    time.sleep(1)

profile.run('go()')


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131540&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 16:33:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 08:33:19 -0800
Subject: [Python-bugs-list] [Bug #131560] pdb imports 'repr', causing name collision
Message-ID: <E14Qu0V-0003CC-00@usw-sf-web3.sourceforge.net>

Bug #131560, was updated on 2001-Feb-08 08:33
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: gward
Assigned to : nobody
Summary: pdb imports 'repr', causing name collision

Details: It's apparently impossible to debug code that calls the
built-in function 'repr', because pdb.py imports the
repr module, resulting in a "call of non-function (type module)"
traceback.

Here's my example script:
$ cat r.py
print repr(0.1)

And here's what happens when I run it through the debugger:

$ python2.0 [...]/pdb.py r.py
> /tmp/<string>(0)?()
(Pdb) c
> /tmp/<string>(1)?()
(Pdb) c
TypeError: 'call of non-...(type module)'
> /tmp/<string>(1)?()
(Pdb) c
Traceback (most recent call last):
  File "/www/python/lib/python2.0/pdb.py", line 943, in ?
    run('execfile(' + `filename` + ')')
  File "/www/python/lib/python2.0/pdb.py", line 878, in run
    Pdb().run(statement, globals, locals)
  File "/www/plat/python2.0/lib/python2.0/bdb.py", line 346, in run
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "r.py", line 1, in ?
    print repr(0.1)
TypeError: call of non-function (type module)

Two obvious fixes: import repr "as" something else, or do "from repr import
repr" instead of "import repr".  Whatever.

I've checked the CVS version, and this bug appears to be still present.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131560&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 17:22:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 09:22:38 -0800
Subject: [Python-bugs-list] [Bug #131235] mpzmodule wont compile with msvc
Message-ID: <E14QumE-0002GC-00@usw-sf-web2.sourceforge.net>

Bug #131235, was updated on 2001-Feb-06 02:10
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Not a Bug
Priority: 5
Submitted by: mpmak
Assigned to : akuchling
Summary: mpzmodule wont compile with msvc

Details: 
Non const initializer in mpzmodule, around line 1587:
is:
PyObject_HEAD_INIT(&PyType_Type)
sholud be:
PyObject_HEAD_INIT(NULL)

and in module initialization:
MPZtype.ob_type = &PyType_Type;


Follow-Ups:

Date: 2001-Feb-08 09:22
By: akuchling

Comment:
This should already be fixed in CVS (someone else reported it for Cygwin). 
Can you grab a copy of the CVS tree and check that it's now OK?

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131235&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 17:22:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 09:22:47 -0800
Subject: [Python-bugs-list] [Bug #131222] Python-2.1a2: HP make continiously runs the configure script
Message-ID: <E14QumN-0001nj-00@usw-sf-web1.sourceforge.net>

Bug #131222, was updated on 2001-Feb-05 23:50
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nascheme
Summary: Python-2.1a2: HP make continiously runs the configure script

Details: Source:		Python-2.1a2
OS:		HP-UX 11.00

Commands:
	./configure  (or ./configure --with-threads=no)
	make

Details:
	Once make finishes compiling Python/dynload_hpux.c, it runs the configure
script, which will continue to run over and over.

.....
        gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include
-DHAVE_CONFIG_H -o Python/traceback.o Python/traceback.c
        gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include
-DHAVE_CONFIG_H -o Python/getopt.o Python/getopt.c
        gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include
-DHAVE_CONFIG_H -o Python/dynload_hpux.o Python/dynload_hpux.c
        if test -f config.status; \
        then /bin/sh config.status --recheck; \
             /bin/sh config.status; \
        else /bin/sh ./configure ; \
        fi
running /bin/sh ./configure  --prefix=/opt/python2 --with-threads=no
--no-create --no-recursion
loading cache ./config.cache
checking MACHDEP... hp-uxB
checking for --without-gcc... no
checking for --with-cxx=<compiler>... no
checking for c++... (cached) c++

....


Follow-Ups:

Date: 2001-Feb-08 09:22
By: akuchling

Comment:
Reassigning to Neil, and reclassifying as a build problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131222&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 17:21:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 09:21:23 -0800
Subject: [Python-bugs-list] [Bug #131304] a few misprints in 2.0 Python/C  API manual
Message-ID: <E14Qul1-0003YK-00@usw-sf-web3.sourceforge.net>

Bug #131304, was updated on 2001-Feb-06 10:33
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : fdrake
Summary: a few misprints in 2.0 Python/C  API manual

Details: In section 7.2.4, Tuple Objects, various
functions, such as PyTuple_Size, PyTuple_GetItem,
PyTuple_GetSlice are listed as taking a PyTupleObject *.
In tupleobject.h they are declared to take PyObject *.
This just causes some warnings I guess.

Also  I see that _PyTuple_Resize is listed as taking a PyTupleObject
*,while in tupleobject.h it is declared to take PyObject **.  I haven't
tried this function but
I suppose this is a more significant difference.

... Since I'm not an expert and just getting started writing an extension I
hope I'm not wasting your time with these.

cheers,
John
John R. Baxter
baxter@math.umn.edu

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131304&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 17:23:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 09:23:22 -0800
Subject: [Python-bugs-list] [Bug #131439] python and Python interfaces should use cc -G for so's
Message-ID: <E14Qumw-0001o9-00@usw-sf-web1.sourceforge.net>

Bug #131439, was updated on 2001-Feb-07 10:52
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: ler
Assigned to : nascheme
Summary: python and Python interfaces should use cc -G for so's

Details: the Python build environment should use cc -G for it's shared
libs.  This is true at *LEAST* on UnixWare.  The ld man page calls this
out. 

The PostgreSQL interface build had to be modified because of this. 

If you need a shell account on a UnixWare 7 box, I can arrange same. 

LER


Follow-Ups:

Date: 2001-Feb-08 09:23
By: akuchling

Comment:
Assigning to Neil.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131439&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 17:24:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 09:24:13 -0800
Subject: [Python-bugs-list] [Bug #131328] fcntl module functions should accept file module arguments.
Message-ID: <E14Qunl-0002Gr-00@usw-sf-web2.sourceforge.net>

Bug #131328, was updated on 2001-Feb-06 13:28
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Submitted by: esr
Assigned to : akuchling
Summary: fcntl module functions should accept file module arguments.

Details: 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.


Follow-Ups:

Date: 2001-Feb-08 09:24
By: akuchling

Comment:
Assigning to akuchling.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131328&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 17:25:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 09:25:54 -0800
Subject: [Python-bugs-list] [Bug #131480] __test__() should auto-exec at compile time
Message-ID: <E14QupO-0003am-00@usw-sf-web3.sourceforge.net>

Bug #131480, was updated on 2001-Feb-07 18:44
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: justinshaw
Assigned to : nobody
Summary: __test__() should auto-exec at compile time

Details: We can make unit testing as simple as writing the test code!
Everyone agrees that unit tests are worth while.  Python does a great job
removing tedium from the job of the programmer.  Unit test should run
automatically.  Here's a method everyone can agree to:

Have the compiler check each module for a funtion with the special name
'__test__' that takes no arguments.  If it finds it it calls it.

The problem of unit testing divides esiliy into two pieces: How to create
the code and how to execute the code.  There are many options in creating
the code but I have never seen any nice solutions to run the code
automatically
"if __name__ == '__main__':"
 doesn't count since you have to do somthing special to call the code i.e.
run it as a script.  There are of course ways to run the test code
automatically but the ways I have figured out run it on every import (way
too often especially for long tests).  I imagine there is a way to check to
see if the module is loaded from a .pyc file and execute test code
accouringly but this seems a bit kludgy.  Here are the benifits of compile
time auto-execution:

- Compatible with every testing framework.
- Called always and only when it needs to be executed.
- So simple even micro projects 'scripts' can take advantage

Disadvantages:
- Another special name, '__test__'
- If there are more please tell me!

I looked around the source-code and think I see the location where we can
do this.  It's would be a piece of cake and the advantages far outway the
disadvantages.  If I get some support I'd love to incorporate the fix.

Justin Shaw
thomas.j.shaw@aero.org

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131480&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 17:25:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 09:25:35 -0800
Subject: [Python-bugs-list] [Bug #131237] multiple symbol definition - Py_DebugFlag
Message-ID: <E14Qup5-0002Hk-00@usw-sf-web2.sourceforge.net>

Bug #131237, was updated on 2001-Feb-06 02:17
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: mpmak
Assigned to : jhylton
Summary: multiple symbol definition - Py_DebugFlag

Details: 
Some modules have its own definition of varius python core variables. MSVC
will only compile them if storage class is the same
__declspec(dllexport).

firstsets.c, grammar.c, pgen.c : Py_DebugFlag and Py_VerboseFlag

pgenmain.c : Py_DebugFlags, Py_VerboseFlag, Py_FatalError,
PySys_WriteStderr


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131237&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 20:55:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 12:55:40 -0800
Subject: [Python-bugs-list] [Bug #129718] file locking lossage
Message-ID: <E14Qy6O-0003qF-00@usw-sf-web2.sourceforge.net>

Bug #129718, was updated on 2001-Jan-22 12:43
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : bwarsaw
Summary: file locking lossage

Details: (reference:
http://www.erlenstar.demon.co.uk/unix/faq_3.html#SEC35)

there are 4 ways to lock a file in unix.
fcntl, lockf, flock and dotlocking.

the only portable ways are fcntl and dotfiles. dotlocking
is more nfs-resistant. (actually the only reliable
nfs-resistant way seems to be a combination.
see eg.
http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=43491)

both fcntl and dotlock require magic incantations to
implement. therefore it is desireable to include code
to do this in the standard python library.

there is only one module in the python distribution
that implements dot-locking or fcntl() locking:
the posixfile module.

however, it is marked as obsolete(!) because someone
misguidedly thinked the sysv lockf is more portable.

this leads to a situation where the most sensible
low-effort way to implement file locking is to
either cut-n-paste code from the posixfile module,
or to call an external program (such as lockfile(1)
from the procmail package) to do it.

  -- Erno Kuusela
     erno@iki.fi


Follow-Ups:

Date: 2001-Feb-08 12:55
By: donnc

Comment:
It isn't the prettiest thing in Python, but
I wouldn't have thought fcntl.lockf() would
be such a problem.  I get lockf() even on Ultrix!
In every case I can find, it's implemented per
X/Open to make the same locks as fcntl(), so the
choice between one or the other is only API.
Is it worse than I know?  (I'm just a mildly
interested member of the general Python user
public, not speaking for anyone.)
-------------------------------------------------------

Date: 2001-Jan-26 10:28
By: fdrake

Comment:
Assigned to Barry, since he deals with file locking the most these days.
-------------------------------------------------------

Date: 2001-Jan-22 13:25
By: nobody

Comment:
(i apologise for the irritated tone of the above
report.)

it apperas the approach used in posixfile is not so bullet-proof either. in
addition of the layout of the flock struct being platform-dependent,
it is also (at least on linux) dependent also
of the compilation mode used. if python
is compiled with a 64-bit file offsets,
the start and len members can grow in size.
so this would either need to be done in c code
or the code should test for the file offset
size (i don't know if it's possible to find this
out in python code).

  -- erno
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129718&group_id=5470


From noreply@sourceforge.net  Thu Feb  8 21:00:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 13:00:51 -0800
Subject: [Python-bugs-list] [Bug #129991] build process references ld_so_aix in lib before it exists
Message-ID: <E14QyBP-0005DB-00@usw-sf-web3.sourceforge.net>

Bug #129991, was updated on 2001-Jan-24 16:22
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: bcollar
Assigned to : akuchling
Summary: build process references ld_so_aix in lib before it exists

Details: Platform: AIX 4.2.1. performed ./configure --without-gcc
--without-threads --prefix=/development/utils. Had to do --without-threads
because otherwise it builds, but core dumps. make CC=xlC OPT="-O2
-qmaxmem=4000".

make bombs because there is not a directory called
/development/utils/lib/python2.1. Here is the relevant output from make:

running build
running build_ext
building 'struct' extension
skipping /development/utils/src/Python-2.1a1/Modules/structmodule.c
(build/temp.aix-2-000310094C00-2.1/structmodule.o up-to-date)
/development/utils/lib/python2.1/config/ld_so_aix cc
-bI:/development/utils/lib/python2.1/config/python.exp
build/temp.aix-2-000310094C00-2.1/structmodule.o -L/usr/local/lib -o
build/lib.aix-2-000310094C00-2.1/struct.so
unable to execute /development/utils/lib/python2.1/config/ld_so_aix: No
such file or directory
error: command '/development/utils/lib/python2.1/config/ld_so_aix' failed
with exit status 1
make: 1254-004 The error code from the last command is 1.


Follow-Ups:

Date: 2001-Feb-08 13:00
By: donnc

Comment:
Proposed patch 103679 addresses this problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129991&group_id=5470


From bcollar@cs.unm.edu  Thu Feb  8 23:14:37 2001
From: bcollar@cs.unm.edu (Benjamin Collar)
Date: Thu, 8 Feb 2001 16:14:37 -0700 (MST)
Subject: [Python-bugs-list] AIX build problems (Re: [Bug #129995] segfaults
 on AIX if configured  with threads, Re:Bug #129991)
In-Reply-To: <3A829594.37A688B4@lemburg.com>
Message-ID: <Pine.LNX.4.21.0102081605320.5738-100000@jah.cs.unm.edu>

On Thu, 8 Feb 2001, M.-A. Lemburg wrote:

> Could you submit a patch for these changes (configure.in and
> Misc/AIX-NOTES), so that we can get them into 2.1 ? Thanks.
the makexp_aix patch is #103694. I just looked again at AIX-NOTES and it
does mention to use *_r compilers...I didn't understand it very well in
the first place, so my apologies for bothering you all with the bug!

> Perhaps there's also a way to have configure.in use the cc_r
> compiler when building with threads ?!
Likely, but I'm pretty clueless when it comes to doing configure.in's.

> ld_so_aix lives in Modules/ too (and is not built from another
> source). Looking at the above shell lines, it seems that ld_so_aix
> is not installed properly before running setup.py.
> 
> Could you check whether these two utilities are in fact installed
> in lib/python2.1/config/ ?
there is nothing in lib related to python2.1...that's why it confused me
so.

> To fix the ld_so_aix problem, you will have to insert a Modules/
> in the configure.in line as well:
> 
>         case $ac_sys_system/$ac_sys_release in
>         AIX*) LDSHARED="\$(srcdir)/ld_so_aix \$(CC)";;

I submitted a patch for this as well, the number is 103695.

Thanks you all for the help! Keep up the good work :)

Ben



From noreply@sourceforge.net  Fri Feb  9 02:16:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 18:16:59 -0800
Subject: [Python-bugs-list] [Bug #131635] ConfigParser module regexp issue
Message-ID: <E14R37L-0007UO-00@usw-sf-web3.sourceforge.net>

Bug #131635, was updated on 2001-Feb-08 18:16
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: ConfigParser module regexp issue

Details: In the ConfigParser module, a section header with a space
character is not allowed by the regexp search function.  This disallows
parsing of GNOME desktop application files
(/usr/share/gnome/apps/*/*.desktop on Red Hat 7.0).  Also, the option
regexp search errors on internationalized options such as the line:
Name[bg]=Vim

System: Red Hat 7.0
Python version: 1.5.2 (Red Hat packaged)


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131635&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 03:01:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 19:01:16 -0800
Subject: [Python-bugs-list] [Bug #131237] multiple symbol definition - Py_DebugFlag
Message-ID: <E14R3oC-0006Hn-00@usw-sf-web2.sourceforge.net>

Bug #131237, was updated on 2001-Feb-06 02:17
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Submitted by: mpmak
Assigned to : tim_one
Summary: multiple symbol definition - Py_DebugFlag

Details: 
Some modules have its own definition of varius python core variables. MSVC
will only compile them if storage class is the same
__declspec(dllexport).

firstsets.c, grammar.c, pgen.c : Py_DebugFlag and Py_VerboseFlag

pgenmain.c : Py_DebugFlags, Py_VerboseFlag, Py_FatalError,
PySys_WriteStderr


Follow-Ups:

Date: 2001-Feb-08 19:01
By: tim_one

Comment:
Reassigned to me, closed as NotABug.

You should compile Python under MSVC using the MSVC workspace
PCbuild\python.dsw.  See readme.txt in that directory for details.  You
should see no warnings or errors (I sure don't, and I've been doing it
every day for months <wink>).

grammar.c etc are NOT normally compiled on Windows, and, indeed, python.dsw
has no idea they exist.  They're only used when the Python grammar changes,
and the parser tables need to be rebuilt as a result.  That step is
normally done on a Unix system, and the results checked in and merely used
on Windows.  For example, Parser\metagrammar.c is an output of this
process, but is just an input to the Windows build.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131237&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 03:02:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 19:02:20 -0800
Subject: [Python-bugs-list] [Bug #131328] fcntl module functions should accept file module arguments.
Message-ID: <E14R3pE-0006IJ-00@usw-sf-web2.sourceforge.net>

Bug #131328, was updated on 2001-Feb-06 13:28
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Submitted by: esr
Assigned to : akuchling
Summary: fcntl module functions should accept file module arguments.

Details: 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.


Follow-Ups:

Date: 2001-Feb-08 19:02
By: tim_one

Comment:
Care to add mmap.mmap while you're at it?
-------------------------------------------------------

Date: 2001-Feb-08 09:24
By: akuchling

Comment:
Assigning to akuchling.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131328&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 05:50:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 21:50:26 -0800
Subject: [Python-bugs-list] [Bug #131652] cPickle calls string.joinfields()
Message-ID: <E14R6Ru-0007Lw-00@usw-sf-web2.sourceforge.net>

Bug #131652, was updated on 2001-Feb-08 21:50
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: cPickle calls string.joinfields()

Details: Marc-Andre noted in a msg to Import-sig that cPickle, in
O_writelines() (and where else?) is importing the string module and calling
its joinfields function. This could be done much more efficiently by
calling a string method...

--Guido

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131652&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 05:56:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 21:56:49 -0800
Subject: [Python-bugs-list] [Bug #131653] compile.py, mentioned in documentation, unaccessible
Message-ID: <E14R6Y5-0006ep-00@usw-sf-web1.sourceforge.net>

Bug #131653, was updated on 2001-Feb-08 21:56
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: compile.py, mentioned in documentation, unaccessible

Details: In "Extending and Embedding the Python Interpreter" section 3.1
(reference for Windows platform) refers to getting David Ascher's
"compile.py" from http://starship.python.net/crew/da/compile/

This link is dead.  I have tried to follow this up with David Ascher, but
haven't received a response.  So, after a couple of days waiting, I am
submitting it here as a bug in the documentation.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131653&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 07:08:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 23:08:28 -0800
Subject: [Python-bugs-list] [Bug #131225] sys.winver is still '2.0' in python 2.1a2
Message-ID: <E14R7fQ-0000uU-00@usw-sf-web3.sourceforge.net>

Bug #131225, was updated on 2001-Feb-06 00:25
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Submitted by: theller
Assigned to : mhammond
Summary: sys.winver is still '2.0' in python 2.1a2

Details: sys.winver is still '2.0' in python 2.1a2 although the registry
entries are stored under 2.1a2.

(Also the version resources, displayed when rightclicked in explorer, look
a little strange, but I dont't really care).

Follow-Ups:

Date: 2001-Feb-08 23:08
By: tim_one

Comment:
Marked Fixed, but left Open and reassigned to MarkH so he doesn't miss that
this changed.  Mark, review the change and gripe if appropriate!  Else just
close this bug.  PC/python_nt.rc rev 1.12.

Checkin comment:
SF bug #131225: sys.winver is still '2.0' in python 2.1a2.
SF patch #103683: Alternative dll version resources.
Changes similar to the patch.  MarkH should review.
File version and Product version text strings now 2.1a2.
64-bit file and product version numbers are now
    PY_MAJOR_VERSION, PY_MINOR_VERSION, messy, PYTHON_API_VERSION
where
    messy = PY_MICRO_VERSION*1000 + PY_RELEASE_LEVEL*10 +
PY_RELEASE_SERIAL
Updated company name to "Digital Creations 2".
Copyright now lists Guido; "C in a circle" symbol used instead of (C).
Comments added so this is less likely to get flubbed again, and #if/#error
guys added to trigger if the version number manipulations above overflow.
-------------------------------------------------------

Date: 2001-Feb-08 05:12
By: lhudson

Comment:
This is bit of a nasty one as it causes pywintypes20.dll and
pythoncom20.dll to be loaded instead of the 21 versions
(PyWin_FindRegisteredModule behaviour).

Patch #103683 fixes this problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131225&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 07:15:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 08 Feb 2001 23:15:42 -0800
Subject: [Python-bugs-list] [Bug #131225] sys.winver is still '2.0' in python 2.1a2
Message-ID: <E14R7mQ-00075W-00@usw-sf-web1.sourceforge.net>

Bug #131225, was updated on 2001-Feb-06 00:25
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Submitted by: theller
Assigned to : mhammond
Summary: sys.winver is still '2.0' in python 2.1a2

Details: sys.winver is still '2.0' in python 2.1a2 although the registry
entries are stored under 2.1a2.

(Also the version resources, displayed when rightclicked in explorer, look
a little strange, but I dont't really care).

Follow-Ups:

Date: 2001-Feb-08 23:15
By: mhammond

Comment:
Thanks.  Closed.
-------------------------------------------------------

Date: 2001-Feb-08 23:08
By: tim_one

Comment:
Marked Fixed, but left Open and reassigned to MarkH so he doesn't miss that
this changed.  Mark, review the change and gripe if appropriate!  Else just
close this bug.  PC/python_nt.rc rev 1.12.

Checkin comment:
SF bug #131225: sys.winver is still '2.0' in python 2.1a2.
SF patch #103683: Alternative dll version resources.
Changes similar to the patch.  MarkH should review.
File version and Product version text strings now 2.1a2.
64-bit file and product version numbers are now
    PY_MAJOR_VERSION, PY_MINOR_VERSION, messy, PYTHON_API_VERSION
where
    messy = PY_MICRO_VERSION*1000 + PY_RELEASE_LEVEL*10 +
PY_RELEASE_SERIAL
Updated company name to "Digital Creations 2".
Copyright now lists Guido; "C in a circle" symbol used instead of (C).
Comments added so this is less likely to get flubbed again, and #if/#error
guys added to trigger if the version number manipulations above overflow.
-------------------------------------------------------

Date: 2001-Feb-08 05:12
By: lhudson

Comment:
This is bit of a nasty one as it causes pywintypes20.dll and
pythoncom20.dll to be loaded instead of the 21 versions
(PyWin_FindRegisteredModule behaviour).

Patch #103683 fixes this problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131225&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 11:53:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 03:53:09 -0800
Subject: [Python-bugs-list] [Bug #129991] build process references ld_so_aix in lib before it exists
Message-ID: <E14RC6v-0000Ue-00@usw-sf-web1.sourceforge.net>

Bug #129991, was updated on 2001-Jan-24 16:22
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: bcollar
Assigned to : lemburg
Summary: build process references ld_so_aix in lib before it exists

Details: Platform: AIX 4.2.1. performed ./configure --without-gcc
--without-threads --prefix=/development/utils. Had to do --without-threads
because otherwise it builds, but core dumps. make CC=xlC OPT="-O2
-qmaxmem=4000".

make bombs because there is not a directory called
/development/utils/lib/python2.1. Here is the relevant output from make:

running build
running build_ext
building 'struct' extension
skipping /development/utils/src/Python-2.1a1/Modules/structmodule.c
(build/temp.aix-2-000310094C00-2.1/structmodule.o up-to-date)
/development/utils/lib/python2.1/config/ld_so_aix cc
-bI:/development/utils/lib/python2.1/config/python.exp
build/temp.aix-2-000310094C00-2.1/structmodule.o -L/usr/local/lib -o
build/lib.aix-2-000310094C00-2.1/struct.so
unable to execute /development/utils/lib/python2.1/config/ld_so_aix: No
such file or directory
error: command '/development/utils/lib/python2.1/config/ld_so_aix' failed
with exit status 1
make: 1254-004 The error code from the last command is 1.


Follow-Ups:

Date: 2001-Feb-09 03:53
By: lemburg

Comment:
Patch checked in.
-------------------------------------------------------

Date: 2001-Feb-08 13:00
By: donnc

Comment:
Proposed patch 103679 addresses this problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129991&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 15:07:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 07:07:27 -0800
Subject: [Python-bugs-list] [Bug #131725] Making documentation requires Python 2.0+
Message-ID: <E14RF8x-0004Pi-00@usw-sf-web3.sourceforge.net>

Bug #131725, was updated on 2001-Feb-09 07:07
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: jnelson
Assigned to : nobody
Summary: Making documentation requires Python 2.0+

Details: The python scripts which come with the Python2.1a2 
tarball require features not available in Python 1.5.2

Also, the scripts use /usr/bin/env python
instead of 
/usr/bin/env python{1.6,2.0,2.1} etc...

A patch is included.

diff -u -r Python-2.1a2/Doc/tools/mkhowto
foo/Python-2.1a2/Doc/tools/mkhowto
--- Python-2.1a2/Doc/tools/mkhowto	Tue Jan 30 16:30:01 2001
+++ foo/Python-2.1a2/Doc/tools/mkhowto	Fri Feb  9 08:25:42 2001
@@ -297,7 +297,7 @@
             # let the doctype-specific handler do some intermediate
work:
             #
             self.run("%s %s" % (binary, self.doc))
-            self.latex_runs += 1
+            self.latex_runs = self.latex_runs + 1
             if os.path.isfile("mod%s.idx" % self.doc):
                 self.run("%s -s %s mod%s.idx"
                          % (MAKEINDEX_BINARY, ISTFILE, self.doc))
@@ -319,7 +319,7 @@
         if self.use_bibtex:
             self.run("%s %s" % (BIBTEX_BINARY, self.doc))
         self.run("%s %s" % (binary, self.doc))
-        self.latex_runs += 1
+        self.latex_runs = self.latex_runs + 1
 
     def process_synopsis_files(self):
         synopsis_files = glob.glob(self.doc + "*.syn")
diff -u -r Python-2.1a2/Doc/tools/mkmodindex
foo/Python-2.1a2/Doc/tools/mkmodindex
--- Python-2.1a2/Doc/tools/mkmodindex	Tue Nov 28 10:20:50 2000
+++ foo/Python-2.1a2/Doc/tools/mkmodindex	Fri Feb  9 08:27:30 2001
@@ -117,9 +117,9 @@
     html = string.join(parts, '')
     program = os.path.basename(sys.argv[0])
     fp = options.get_output_file()
-    print >>fp, html.rstrip()
+    fp.write( html.rstrip() + "\n" )
     if options.outputfile == "-":
-        print >>sys.stderr, "%s: %d index nodes" % (program, num_nodes)
+        sys.stderr.write("%s: %d index nodes\n" % (program, num_nodes))
     else:
         print
         print "%s: %d index nodes" % (program, num_nodes)
diff -u -r Python-2.1a2/Doc/tools/support.py
foo/Python-2.1a2/Doc/tools/support.py
--- Python-2.1a2/Doc/tools/support.py	Thu Oct  5 00:20:55 2000
+++ foo/Python-2.1a2/Doc/tools/support.py	Fri Feb  9 08:32:50 2001
@@ -9,6 +9,7 @@
 
 import getopt
 import sys
+import string
 
 
 class Options:
@@ -37,9 +38,9 @@
 
     def add_args(self, short=None, long=None):
         if short:
-            self.__short_args += short
+            self.__short_args = self.__short_args + short
         if long:
-            self.__long_args += long
+            self.__long_args = self.__long_args + long
 
     def parse(self, args):
         try:
@@ -49,10 +50,10 @@
             sys.stdout = sys.stderr
             self.usage()
             sys.exit(2)
-        self.args += args
+        self.args = self.args + args
         for opt, val in opts:
             if opt in ("-a", "--address"):
-                val = val.strip()
+                val = string.strip(val)
                 if val:
                     val = "<address>\n%s\n</address>\n" % val
                     self.variables["address"] = val


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131725&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 18:32:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 10:32:37 -0800
Subject: [Python-bugs-list] [Bug #131756] [Linux 2.2.19] make test fails CVS HEAD
Message-ID: <E14RILV-0003CP-00@usw-sf-web1.sourceforge.net>

Bug #131756, was updated on 2001-Feb-09 10:32
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: [Linux 2.2.19] make test fails CVS HEAD

Details: I hope this belongs to build category.

For a few weeks I have tracked CVS HEAD, compiling every few
days to test new python features. Up until approximately one
week ago, everything was fine. make distclean, cvs update,
./configure, make, make test then proceed to test new
interpreter.

Recently (last week or so) make test is failing miserably:
./python -c 'import sys ; from distutils.util import get_platform ; print
get_platform()+"-"+sys.version[0:3]' >platform
rm -f ./Lib/test/*.py[co]
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 38, in ?
    import random
  File "/home/gbsadler/cvs/python/dist/src/Lib/random.py", line 76, in ?
    from math import log as _log, exp as _exp, pi as _pi, e as _e
ImportError: No module named math
make: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 38, in ?
    import random
  File "/home/gbsadler/cvs/python/dist/src/Lib/random.py", line 76, in ?
    from math import log as _log, exp as _exp, pi as _pi, e as _e
ImportError: No module named math
make: *** [test] Error 1

I realize the README says not to send the results of make test
but...

gbsadler@xxx:~/cvs/python/dist/src$ ./python Lib/test/regrtest.py
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 38, in ?
    import random
  File "/home/gbsadler/cvs/python/dist/src/Lib/random.py", line 76, in ?
    from math import log as _log, exp as _exp, pi as _pi, e as _e
ImportError: No module named math

Same effect if I just load the new interpreter and try to
import math

I tried to check recent changes to setup.py and/or Makefile.pre.in.
However, only check-in that remotely looks to maybe affect
this from my limited understanding... is a change to Makefile.pre.in
to add oldsharedmods to all: target?

Hope this is worked out, love python here. -)
gbsadler1@lcisp.com
Gordon Sadler

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131756&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 21:57:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 13:57:11 -0800
Subject: [Python-bugs-list] [Bug #131774] Architecture-specific config.h is badly named
Message-ID: <E14RLXT-0007RP-00@usw-sf-web3.sourceforge.net>

Bug #131774, was updated on 2001-Feb-09 13:57
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: gramirez
Assigned to : nobody
Summary: Architecture-specific config.h is badly named

Details: If Python is installed with architecture-dependent and
architecture-independent files in separate locations (using --prefix and
--exec-prefix), then config.h is placed in a directory different than
Python.h (and pyport.h and pgenheaders.h, which also #include
"config.h").

If I build a python module which has its own config.h (like pygtk), the
build fails because Python.h #include's the *wrong* config.h. I cannot
easily change the order of the
-I flags when compiling pygtk because autoconf places its flags
(AM_CPPFLAGS) before any CPPFLAGS that I define in the CPPFLAGS environment
variable.

It would be cleaner to follow the glib model which names its installed
arch-specific file "glibconfig.h". We could install config.h as
pythonconfig.h, and have Python.h #include "pythonconfig.h"



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131774&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 22:10:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 14:10:20 -0800
Subject: [Python-bugs-list] [Bug #131774] Architecture-specific config.h is badly named
Message-ID: <E14RLkC-0005og-00@usw-sf-web2.sourceforge.net>

Bug #131774, was updated on 2001-Feb-09 13:57
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Submitted by: gramirez
Assigned to : nobody
Summary: Architecture-specific config.h is badly named

Details: If Python is installed with architecture-dependent and
architecture-independent files in separate locations (using --prefix and
--exec-prefix), then config.h is placed in a directory different than
Python.h (and pyport.h and pgenheaders.h, which also #include
"config.h").

If I build a python module which has its own config.h (like pygtk), the
build fails because Python.h #include's the *wrong* config.h. I cannot
easily change the order of the
-I flags when compiling pygtk because autoconf places its flags
(AM_CPPFLAGS) before any CPPFLAGS that I define in the CPPFLAGS environment
variable.

It would be cleaner to follow the glib model which names its installed
arch-specific file "glibconfig.h". We could install config.h as
pythonconfig.h, and have Python.h #include "pythonconfig.h"



Follow-Ups:

Date: 2001-Feb-09 14:10
By: gvanrossum

Comment:
Good idea!  Patch anybody?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131774&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:29:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:29:06 -0800
Subject: [Python-bugs-list] [Bug #131560] pdb imports 'repr', causing name collision
Message-ID: <E14RMyQ-0006M4-00@usw-sf-web2.sourceforge.net>

Bug #131560, was updated on 2001-Feb-08 08:33
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: gward
Assigned to : gward
Summary: pdb imports 'repr', causing name collision

Details: It's apparently impossible to debug code that calls the
built-in function 'repr', because pdb.py imports the
repr module, resulting in a "call of non-function (type module)"
traceback.

Here's my example script:
$ cat r.py
print repr(0.1)

And here's what happens when I run it through the debugger:

$ python2.0 [...]/pdb.py r.py
> /tmp/<string>(0)?()
(Pdb) c
> /tmp/<string>(1)?()
(Pdb) c
TypeError: 'call of non-...(type module)'
> /tmp/<string>(1)?()
(Pdb) c
Traceback (most recent call last):
  File "/www/python/lib/python2.0/pdb.py", line 943, in ?
    run('execfile(' + `filename` + ')')
  File "/www/python/lib/python2.0/pdb.py", line 878, in run
    Pdb().run(statement, globals, locals)
  File "/www/plat/python2.0/lib/python2.0/bdb.py", line 346, in run
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "r.py", line 1, in ?
    print repr(0.1)
TypeError: call of non-function (type module)

Two obvious fixes: import repr "as" something else, or do "from repr import
repr" instead of "import repr".  Whatever.

I've checked the CVS version, and this bug appears to be still present.


Follow-Ups:

Date: 2001-Feb-09 15:29
By: tim_one

Comment:
Marked as Fixed and assigned back to you.
Please try CVS Python again (pdb.py, rev 1.51).
I added
from repr import repr as _saferep

If this works OK for you, just change the bug to Closed, else assign back
to me.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131560&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:29:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:29:33 -0800
Subject: [Python-bugs-list] [Bug #130029] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E14RMyr-0006MS-00@usw-sf-web2.sourceforge.net>

Bug #130029, was updated on 2001-Jan-25 02:55
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: nobody
Assigned to : gvanrossum
Summary: [HP-UX] Python chokes on pthread_mutex_init

Details: On an HPUX 11.00:  During "make intstall":

./install-sh -c -m 644 ./Lib/curses/__init__.py
/opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/ascii.py
/opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/has_key.py
/opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/textpad.py
/opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/wrapper.py
/opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/plat-hp-uxB/core
/opt/tmp/Python/lib/python2.0/plat-hp-uxB
./install-sh -c -m 755 ./Lib/plat-hp-uxB/regen
/opt/tmp/Python/lib/python2.0/plat-hp-uxB
        ./install-sh -c -m 644 ./LICENSE
/opt/tmp/Python/lib/python2.0/LICENSE.txt
        PYTHONPATH=/opt/tmp/Python/lib/python2.0 \
                        ./python -tt
/opt/tmp/Python/lib/python2.0/compileall.py /opt/tmp/Python/lib/python2.0
pthread_mutex_init: Invalid argument
sh: 6074 Memory fault(coredump)

----------------------------------------------------------
This fault can be reproduced:

export PYTHONPATH=/opt/tmp/Python/lib/python2.0

/opt/stephie/Python-2.0 > ./python -tt
/opt/tmp/Python/lib/python2.0/compileall.py /opt/tmp/Python/lib/python2.0
pthread_mutex_init: Invalid argument
Memory fault(coredump)



Follow-Ups:

Date: 2001-Feb-09 15:29
By: tim_one

Comment:
Assigned to our resident HP-UX fan <wink>.
-------------------------------------------------------

Date: 2001-Feb-01 12:10
By: fdrake

Comment:
This may be the same bug as #110650 (already closed, but not clear that
this was ever actually fixed).

Too bad this was an anonymous report; we can't ask for more information
without an email address.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130029&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:30:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:30:19 -0800
Subject: [Python-bugs-list] [Bug #131170] make install fails on macosx for Python-2.1a2
Message-ID: <E14RMzb-0006Mt-00@usw-sf-web2.sourceforge.net>

Bug #131170, was updated on 2001-Feb-05 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: sdm7g
Assigned to : nascheme
Summary: make install fails on macosx for Python-2.1a2

Details: Python-2.1a2 on macosx 
make install fails trying to ranlib the shared library:

ranlib: file: /usr/local/lib/python2.1/config/libpython2.1.dylib is not an
archive

(This bug wasn't in 2.0, and I don't think was in 2.1a1.)

-- Steve M.

Follow-Ups:

Date: 2001-Feb-09 15:30
By: tim_one

Comment:
Assigned to Neil for the heck of it.
-------------------------------------------------------

Date: 2001-Feb-07 19:43
By: sdm7g

Comment:
Well, the missing libtool switch to tell it the
library will be installed somewhere else is:

 -install_name  $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to
be unable to find the os.module and sys.path
is set all  wrong. (and it fails somewhere 
else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK
conditional code in getpath.c is getting
the path not from the executable, but from
the library. 

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

Date: 2001-Feb-07 19:42
By: sdm7g

Comment:
Well, the missing libtool switch to tell it the
library will be installed somewhere else is:

 -install_name  $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to
be unable to find the os.module and sys.path
is set all  wrong. (and it fails somewhere 
else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK
conditional code in getpath.c is getting
the path not from the executable, but from
the library. 

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

Date: 2001-Feb-07 19:34
By: sdm7g

Comment:
Well, the missing libtool switch to tell it the
library will be installed somewhere else is:

 -install_name  $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to
be unable to find the os.module and sys.path
is set all  wrong. (and it fails somewhere 
else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK
conditional code in getpath.c is getting
the path not from the executable, but from
the library. 

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

Date: 2001-Feb-07 15:07
By: sdm7g

Comment:
Note: after removing the ranlib, installation succeeds, and the program
works when you are in
the python directory, however, running the installed program from somewhere
else gives the 
fatal error:

dyld: python2.1 can't open library: libpython2.1.dylib  (No such file or
directory, errno = 2)

If you look at the python executable with 
"otool -L" , you can see that system frameworks,
for example, have their complete pathnames, while
libpython2.1.dylib has no path, so it's expected 
in the current directory. 

(looking for the libtool option to correct this...)  -- Steve M. 
-------------------------------------------------------

Date: 2001-Feb-05 13:12
By: nobody

Comment:
Commenting out the $(RANLIB) line in the
install section of Makefile seems to fix the problem on macosx, but I don't
know if it is a problemon any other platforms. 

       @if test -d $(LDLIBRARY); then :; else \
                $(INSTALL_DATA) $(LDLIBRARY) $(LIBPL)/$(LDLIBRARY) ; \
#               $(RANLIB) $(LIBPL)/$(LDLIBRARY) ; \

-- Steve M.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131170&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:32:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:32:15 -0800
Subject: [Python-bugs-list] [Bug #131652] cPickle calls string.joinfields()
Message-ID: <E14RN1T-0005ev-00@usw-sf-web1.sourceforge.net>

Bug #131652, was updated on 2001-Feb-08 21:50
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : jhylton
Summary: cPickle calls string.joinfields()

Details: Marc-Andre noted in a msg to Import-sig that cPickle, in
O_writelines() (and where else?) is importing the string module and calling
its joinfields function. This could be done much more efficiently by
calling a string method...

--Guido

Follow-Ups:

Date: 2001-Feb-09 15:32
By: jhylton

Comment:
sounds good to me

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131652&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:32:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:32:46 -0800
Subject: [Python-bugs-list] [Bug #131635] ConfigParser module regexp issue
Message-ID: <E14RN1y-0005fM-00@usw-sf-web1.sourceforge.net>

Bug #131635, was updated on 2001-Feb-08 18:16
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Submitted by: nobody
Assigned to : fdrake
Summary: ConfigParser module regexp issue

Details: In the ConfigParser module, a section header with a space
character is not allowed by the regexp search function.  This disallows
parsing of GNOME desktop application files
(/usr/share/gnome/apps/*/*.desktop on Red Hat 7.0).  Also, the option
regexp search errors on internationalized options such as the line:
Name[bg]=Vim

System: Red Hat 7.0
Python version: 1.5.2 (Red Hat packaged)


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131635&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:33:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:33:24 -0800
Subject: [Python-bugs-list] [Bug #131189] Crash when Python Re-Initialized with Daemon Threads
Message-ID: <E14RN2a-0006O3-00@usw-sf-web2.sourceforge.net>

Bug #131189, was updated on 2001-Feb-05 15:04
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: jpettit
Assigned to : gvanrossum
Summary: Crash when Python Re-Initialized with Daemon Threads

Details: When "threadCrash.c" is built and run, it will fail with a
segmentation fault.  It appears Py_Finalize is not properly cleaning up the
threads.  Under the "Bugs and caveats" section of Py_Finalize in the
Python/C API Reference Manual (api\initialization.html), it mentions
various problems, but doesn't mention this one.

I've tested this with Python 2.0 on Win2K, Linux, and OpenBSD.

--------- threadCrash.c ---------

#include "Python.h"

#define THREAD_FILE "simpleThread.py"

main(int argc, char **argv)
{
    FILE *threadScript;

    Py_SetProgramName(argv[0]);

    while (1)
    {
        Py_Initialize();

        threadScript = fopen(THREAD_FILE, "r");

        PyRun_SimpleFile(threadScript, THREAD_FILE);

        fclose(threadScript);

        // Destroy our interpreter for a clean restart
        Py_Finalize();
    }
}

--------- simpleThread.py ---------

import threading
import time

class simple(threading.Thread):
    def __init__(self, idNum):
        threading.Thread.__init__(self)
        self.idNum = idNum

    def run(self):
        while 1:
            print self.idNum
            time.sleep(1)

for i in range(5):
    a = simple(i)
    a.start()

--------- end ---------

Follow-Ups:

Date: 2001-Feb-09 15:33
By: tim_one

Comment:
Assigned to Guido.

jpettit, the whitespace isn't actually destroyed, that's simply what
browsers *do* with runs of whitespace (i.e., they collapse them).  The
leading whitespace is still present in the database, and you'll see it e.g.
in the email SourceForge generates.  We have a request outstanding with
SourceForge to do a better job of this on the web pages (e.g., generating
&nbsp; instead of literal spaces).
-------------------------------------------------------

Date: 2001-Feb-05 15:08
By: jpettit

Comment:
Sorry, the subject line is misleading.  I had originally thought this had
something to do with daemonic threads, but it seems to be a general thread
issue.  Also, it appears that SourceForge likes to eat proceeding white
space, which has munged my Python code.  It should be fairly
straight-forward, though, to determine what I meant.  Is there a preferred
way to submit Python code to SourceForge?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131189&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:33:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:33:29 -0800
Subject: [Python-bugs-list] [Bug #131756] [Linux 2.2.19] make test fails CVS HEAD
Message-ID: <E14RN2f-0005fb-00@usw-sf-web1.sourceforge.net>

Bug #131756, was updated on 2001-Feb-09 10:32
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : akuchling
Summary: [Linux 2.2.19] make test fails CVS HEAD

Details: I hope this belongs to build category.

For a few weeks I have tracked CVS HEAD, compiling every few
days to test new python features. Up until approximately one
week ago, everything was fine. make distclean, cvs update,
./configure, make, make test then proceed to test new
interpreter.

Recently (last week or so) make test is failing miserably:
./python -c 'import sys ; from distutils.util import get_platform ; print
get_platform()+"-"+sys.version[0:3]' >platform
rm -f ./Lib/test/*.py[co]
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 38, in ?
    import random
  File "/home/gbsadler/cvs/python/dist/src/Lib/random.py", line 76, in ?
    from math import log as _log, exp as _exp, pi as _pi, e as _e
ImportError: No module named math
make: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 38, in ?
    import random
  File "/home/gbsadler/cvs/python/dist/src/Lib/random.py", line 76, in ?
    from math import log as _log, exp as _exp, pi as _pi, e as _e
ImportError: No module named math
make: *** [test] Error 1

I realize the README says not to send the results of make test
but...

gbsadler@xxx:~/cvs/python/dist/src$ ./python Lib/test/regrtest.py
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 38, in ?
    import random
  File "/home/gbsadler/cvs/python/dist/src/Lib/random.py", line 76, in ?
    from math import log as _log, exp as _exp, pi as _pi, e as _e
ImportError: No module named math

Same effect if I just load the new interpreter and try to
import math

I tried to check recent changes to setup.py and/or Makefile.pre.in.
However, only check-in that remotely looks to maybe affect
this from my limited understanding... is a change to Makefile.pre.in
to add oldsharedmods to all: target?

Hope this is worked out, love python here. -)
gbsadler1@lcisp.com
Gordon Sadler

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131756&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:33:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:33:41 -0800
Subject: [Python-bugs-list] [Bug #131725] Making documentation requires Python 2.0+
Message-ID: <E14RN2r-0005ff-00@usw-sf-web1.sourceforge.net>

Bug #131725, was updated on 2001-Feb-09 07:07
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: jnelson
Assigned to : fdrake
Summary: Making documentation requires Python 2.0+

Details: The python scripts which come with the Python2.1a2 
tarball require features not available in Python 1.5.2

Also, the scripts use /usr/bin/env python
instead of 
/usr/bin/env python{1.6,2.0,2.1} etc...

A patch is included.

diff -u -r Python-2.1a2/Doc/tools/mkhowto
foo/Python-2.1a2/Doc/tools/mkhowto
--- Python-2.1a2/Doc/tools/mkhowto	Tue Jan 30 16:30:01 2001
+++ foo/Python-2.1a2/Doc/tools/mkhowto	Fri Feb  9 08:25:42 2001
@@ -297,7 +297,7 @@
             # let the doctype-specific handler do some intermediate
work:
             #
             self.run("%s %s" % (binary, self.doc))
-            self.latex_runs += 1
+            self.latex_runs = self.latex_runs + 1
             if os.path.isfile("mod%s.idx" % self.doc):
                 self.run("%s -s %s mod%s.idx"
                          % (MAKEINDEX_BINARY, ISTFILE, self.doc))
@@ -319,7 +319,7 @@
         if self.use_bibtex:
             self.run("%s %s" % (BIBTEX_BINARY, self.doc))
         self.run("%s %s" % (binary, self.doc))
-        self.latex_runs += 1
+        self.latex_runs = self.latex_runs + 1
 
     def process_synopsis_files(self):
         synopsis_files = glob.glob(self.doc + "*.syn")
diff -u -r Python-2.1a2/Doc/tools/mkmodindex
foo/Python-2.1a2/Doc/tools/mkmodindex
--- Python-2.1a2/Doc/tools/mkmodindex	Tue Nov 28 10:20:50 2000
+++ foo/Python-2.1a2/Doc/tools/mkmodindex	Fri Feb  9 08:27:30 2001
@@ -117,9 +117,9 @@
     html = string.join(parts, '')
     program = os.path.basename(sys.argv[0])
     fp = options.get_output_file()
-    print >>fp, html.rstrip()
+    fp.write( html.rstrip() + "\n" )
     if options.outputfile == "-":
-        print >>sys.stderr, "%s: %d index nodes" % (program, num_nodes)
+        sys.stderr.write("%s: %d index nodes\n" % (program, num_nodes))
     else:
         print
         print "%s: %d index nodes" % (program, num_nodes)
diff -u -r Python-2.1a2/Doc/tools/support.py
foo/Python-2.1a2/Doc/tools/support.py
--- Python-2.1a2/Doc/tools/support.py	Thu Oct  5 00:20:55 2000
+++ foo/Python-2.1a2/Doc/tools/support.py	Fri Feb  9 08:32:50 2001
@@ -9,6 +9,7 @@
 
 import getopt
 import sys
+import string
 
 
 class Options:
@@ -37,9 +38,9 @@
 
     def add_args(self, short=None, long=None):
         if short:
-            self.__short_args += short
+            self.__short_args = self.__short_args + short
         if long:
-            self.__long_args += long
+            self.__long_args = self.__long_args + long
 
     def parse(self, args):
         try:
@@ -49,10 +50,10 @@
             sys.stdout = sys.stderr
             self.usage()
             sys.exit(2)
-        self.args += args
+        self.args = self.args + args
         for opt, val in opts:
             if opt in ("-a", "--address"):
-                val = val.strip()
+                val = string.strip(val)
                 if val:
                     val = "<address>\n%s\n</address>\n" % val
                     self.variables["address"] = val


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131725&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:34:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:34:40 -0800
Subject: [Python-bugs-list] [Bug #131207] Fatal Python Error during program shutdown
Message-ID: <E14RN3o-0006Oa-00@usw-sf-web2.sourceforge.net>

Bug #131207, was updated on 2001-Feb-05 18:50
Here is a current snapshot of the bug.

Project: Python
Category: Tkinter
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: djhender
Assigned to : effbot
Summary: Fatal Python Error during program shutdown

Details: 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.

Follow-Ups:

Date: 2001-Feb-09 15:34
By: tim_one

Comment:
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.
-------------------------------------------------------

Date: 2001-Feb-05 21:30
By: djhender

Comment:
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.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131207&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:35:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:35:26 -0800
Subject: [Python-bugs-list] [Bug #131480] __test__() should auto-exec at compile time
Message-ID: <E14RN4Y-0005h1-00@usw-sf-web1.sourceforge.net>

Bug #131480, was updated on 2001-Feb-07 18:44
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Wont Fix
Bug Group: Feature Request
Priority: 5
Submitted by: justinshaw
Assigned to : jhylton
Summary: __test__() should auto-exec at compile time

Details: We can make unit testing as simple as writing the test code!
Everyone agrees that unit tests are worth while.  Python does a great job
removing tedium from the job of the programmer.  Unit test should run
automatically.  Here's a method everyone can agree to:

Have the compiler check each module for a funtion with the special name
'__test__' that takes no arguments.  If it finds it it calls it.

The problem of unit testing divides esiliy into two pieces: How to create
the code and how to execute the code.  There are many options in creating
the code but I have never seen any nice solutions to run the code
automatically
"if __name__ == '__main__':"
 doesn't count since you have to do somthing special to call the code i.e.
run it as a script.  There are of course ways to run the test code
automatically but the ways I have figured out run it on every import (way
too often especially for long tests).  I imagine there is a way to check to
see if the module is loaded from a .pyc file and execute test code
accouringly but this seems a bit kludgy.  Here are the benifits of compile
time auto-execution:

- Compatible with every testing framework.
- Called always and only when it needs to be executed.
- So simple even micro projects 'scripts' can take advantage

Disadvantages:
- Another special name, '__test__'
- If there are more please tell me!

I looked around the source-code and think I see the location where we can
do this.  It's would be a piece of cake and the advantages far outway the
disadvantages.  If I get some support I'd love to incorporate the fix.

Justin Shaw
thomas.j.shaw@aero.org

Follow-Ups:

Date: 2001-Feb-09 15:35
By: jhylton

Comment:
I don't agree that unit tests should run automatically.  Nor do I think
adding magic to the language to support unit tests is necessary when it is
trivial to add some external mechanism.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131480&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:36:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:36:05 -0800
Subject: [Python-bugs-list] [Bug #131249] cgi.py opens too many (temporary) files
Message-ID: <E14RN5B-0005hN-00@usw-sf-web1.sourceforge.net>

Bug #131249, was updated on 2001-Feb-06 04:59
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: stadt
Assigned to : akuchling
Summary: cgi.py opens too many (temporary) files

Details: cgi.FieldStorage() is used to get the contents of a webform. It
turns out that
for each <input> line, a new temporary file is opened. This causes the
script
that is using cgi.FieldStorage() to reach the webserver's limit of number
of
opened files, as described by 'ulimit -n'. The standard value for Solaris
systems
seems to be 64, so webforms with that many <input> fields cannot be dealt
with.

A solution would seem to use the same temporary filename, since only a
maxmimum one file is (temporarily) used at the same time. I did an "ls|wc
-l"
while the script was running, which showed only zeroes and ones.

(I'm using Python for CyberChair, an online paper submission and reviewing
system.
The webform under discussion has one input field for each reviewer, stating
the
papers he or she is supposed to be reviewing. One conference that is using
CyberChair
has almost 140 reviewers. Their system's open file limit is 64. Using the
same data on
a system with an open file limit of 260 _is_ able to deal with this.)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131249&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:37:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:37:18 -0800
Subject: [Python-bugs-list] [Bug #131239] -x flag is ignored on non pyc files
Message-ID: <E14RN6M-0005hq-00@usw-sf-web1.sourceforge.net>

Bug #131239, was updated on 2001-Feb-06 02:30
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mpmak
Assigned to : tim_one
Summary: -x flag is ignored on non pyc files

Details: 
simple script x.bat will raise syntax error in line 1
@python -x "%~f0" %* & goto :EOF
print 'ok'

maybe_pyc_file in pythonrun.c does not save/restore file position when
reading non pyc file which was given as argument on command line.


Follow-Ups:

Date: 2001-Feb-09 15:37
By: jhylton

Comment:
No clue what the .bat file is trying to do.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131239&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:45:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:45:14 -0800
Subject: [Python-bugs-list] [Bug #131652] cPickle calls string.joinfields()
Message-ID: <E14RNE2-0006T8-00@usw-sf-web2.sourceforge.net>

Bug #131652, was updated on 2001-Feb-08 21:50
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : jhylton
Summary: cPickle calls string.joinfields()

Details: Marc-Andre noted in a msg to Import-sig that cPickle, in
O_writelines() (and where else?) is importing the string module and calling
its joinfields function. This could be done much more efficiently by
calling a string method...

--Guido

Follow-Ups:

Date: 2001-Feb-09 15:45
By: jhylton

Comment:
committed as rev. 2.28 of cStringIO.c

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

Date: 2001-Feb-09 15:32
By: jhylton

Comment:
sounds good to me

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131652&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:48:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:48:01 -0800
Subject: [Python-bugs-list] [Bug #131239] -x flag is ignored on non pyc files
Message-ID: <E14RNGj-0006U5-00@usw-sf-web2.sourceforge.net>

Bug #131239, was updated on 2001-Feb-06 02:30
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: mpmak
Assigned to : gvanrossum
Summary: -x flag is ignored on non pyc files

Details: 
simple script x.bat will raise syntax error in line 1
@python -x "%~f0" %* & goto :EOF
print 'ok'

maybe_pyc_file in pythonrun.c does not save/restore file position when
reading non pyc file which was given as argument on command line.


Follow-Ups:

Date: 2001-Feb-09 15:48
By: tim_one

Comment:
Assigned to Guido.  Guido, can you reproduce?  This requires cmd.exe, not
the command.com Win9X uses for a shell (i.e., I can't try it; but you can
under your Win2000).  Hmm.  Under Win98SE, I can put this in x.bat and get
(almost certainly) the same problem (via running x.bat):

python -x x.bat
print "hi"

Nothing special about .bat files!  Have to suspect -x is plain busted.
-------------------------------------------------------

Date: 2001-Feb-09 15:37
By: jhylton

Comment:
No clue what the .bat file is trying to do.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131239&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:50:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:50:24 -0800
Subject: [Python-bugs-list] [Bug #131273] [windows] os.popen doens't kill subprocess when interrupted
Message-ID: <E14RNJ2-0006VK-00@usw-sf-web2.sourceforge.net>

Bug #131273, was updated on 2001-Feb-06 08:43
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: cgouiran
Assigned to : mhammond
Summary: [windows] os.popen doens't kill subprocess when interrupted

Details: Hi, in the following script I liked to make an interface to the
contig program(http://www.sysinternals.com)

As the popen invocation can be a long time process (since it walks
recursively trough directories) I press CTRL-C sometimes and the contig
continues to run.

I use Python 2.0 (BeOpen version) under WinNT 4.0(SP 4)

Maybe I made a mistake in the following script ?

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

#! /usr/bin/env python

import sys;
import os;
import re;

content = ""

mm = re.compile("Processing (.+)?:\nFragments: (\d+)?");

output = os.popen("contig -a -s *.*");

while(1):
  line = output.readline();
	
  if line == '':
    break
	
    content += line;


status = output.close()

if status:
  print("Error contig : "+`status`+"("+os.strerror(status)+")");
  sys.exit(12);

print mm.findall(content)

Follow-Ups:

Date: 2001-Feb-09 15:50
By: tim_one

Comment:
Poor Mark.  I assign anything with "popen + Windows" to you, because you're
the only one who ever makes progress on them <wink>.  Offhand, I can't see
how Ctrl+C directed at Python *could* interrupt a spawned process.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131273&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:50:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:50:50 -0800
Subject: [Python-bugs-list] [Bug #131377] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E14RNJS-0006Vd-00@usw-sf-web2.sourceforge.net>

Bug #131377, was updated on 2001-Feb-07 01:56
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: twallgram
Assigned to : gvanrossum
Summary: [HP-UX] Python chokes on pthread_mutex_init

Details: Hello,
I need python 1.5.2 (only this version) on a HP-UX-System with threads. I
started configure with the --with-threads-Option. Then I did the
'make'-command (No problems during the compilation). Then I started make
test. See the output bellow:

# make test
        (cd Modules; make -f Makefile.pre Makefile)
`Makefile' is up to date.
making Makefile in subdirectory .
`Makefile' is up to date.
making Makefile in subdirectory Parser
`Makefile' is up to date.
making Makefile in subdirectory Objects
`Makefile' is up to date.
making Makefile in subdirectory Python
`Makefile' is up to date.
making Makefile in subdirectory Modules
        (rm -f Modules/hassignal; cd Modules; make hassignal)
        rm -f hassignal
        for i in threadmodule.o  regexmodule.o regexpr.o  pcremodule.o
pypcre.o  posixmodule.o  signalmodule.o  arraymodule.o  cmathmodule.o 
mathmodule.o  stropmodule.o  structmodule.o  timemodule.o  operator.o 
fcntlmodule.o  pwdmodule.o  grpmodule.o  selectmodule.o  socketmodule.o 
errnomodule.o  md5module.o md5c.o  shamodule.o  rotormodule.o  newmodule.o 
binascii.o  parsermodule.o  cStringIO.o  cPickle.o config.o getpath.o
main.o getbuildinfo.o; do \
                    if test "$i" = "signalmodule.o"; then \
                       echo yes >hassignal; break; \
                    fi; \
                done
        cd Parser ; make OPT="-g -O2" VERSION="1.5" \
                        prefix="/usr/local" exec_prefix="/usr/local" all
        cd Objects ; make OPT="-g -O2" VERSION="1.5" \
                        prefix="/usr/local" exec_prefix="/usr/local" all
        cd Python ; make OPT="-g -O2" VERSION="1.5" \
                        prefix="/usr/local" exec_prefix="/usr/local" all
        cd Modules ; make OPT="-g -O2" VERSION="1.5" \
                        prefix="/usr/local" exec_prefix="/usr/local" all
        if test ! -f libpython1.5.a; \
                then for i in Parser Objects Python Modules; do rm -f
$i/add2lib; done; true; \
                else true; fi
        for i in Parser Objects Python Modules; do \
                        (cd $i; make VERSION="1.5" add2lib); done
`add2lib' is up to date.
`add2lib' is up to date.
`add2lib' is up to date.
`add2lib' is up to date.
        rm -f ./Lib/test/*.py[co]
        PYTHONPATH= ./python ./Lib/test/regrtest.py 
pthread_mutex_init: Invalid argument
sh: 11423 Memory fault(coredump)
*** Error exit code 139 (ignored)
        PYTHONPATH= ./python ./Lib/test/regrtest.py 
pthread_mutex_init: Invalid argument
sh: 11425 Memory fault(coredump)
*** Error exit code 139

Stop.

I need python 1.5.2 for compiling Zope 2.0 (which only needs python in this
version with threads). It seems the same error as bug # 130029, but I can
submit a coredump. Can anybody help me? You can use this HP-UX-machine for
checking the compilation :-) 

bye Tom


Follow-Ups:

Date: 2001-Feb-09 15:50
By: tim_one

Comment:
Another for the eternal HP-UX pile.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131377&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:55:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:55:41 -0800
Subject: [Python-bugs-list] [Bug #131398] installation of Numeric for Python 2.0. is impossible
Message-ID: <E14RNO9-0006Xp-00@usw-sf-web2.sourceforge.net>

Bug #131398, was updated on 2001-Feb-07 05:28
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: nobody
Assigned to : akuchling
Summary: installation of Numeric for Python 2.0. is impossible

Details: Hello, everyone.

I have troubles with installing Numeric for Python 2.0.
After I download file Numeric-17.0.tar to directory Python20 and decompress
it there,
I run:

D:\Python20\Numeric-17.3.0>python setup.py install
running install
running build
running build_py
not copying Lib\ArrayPrinter.py (output up-to-date)
not copying Lib\Numeric.py (output up-to-date)
not copying Lib\numeric_version.py (output up-to-date)
not copying Lib\Precision.py (output up-to-date)
not copying Lib\UserArray.py (output up-to-date)
running build_ext
skipping '_numpy' extension (up-to-date)
skipping 'multiarray' extension (up-to-date)
building 'umath' extension
skipping Src/umathmodule.c
(build\temp.win32-2.0\Release\Src/umathmodule.obj up-
to-date)
D:\Program Files\Microsoft Visual Studio\VC98\BIN\link.exe /DLL /nologo
/INCREME
NTAL:NO /LIBPATH:D:\python20\libs m.lib /EXPORT:initumath
build\temp.win32-2.0\R
elease\Src/umathmodule.obj /OUT:build\lib.win32-2.0\umath.pyd
/IMPLIB:build\temp
.win32-2.0\Release\Src\umath.lib
LINK : fatal error LNK1181: cannot open input file "m.lib"
error: command '"D:\Program Files\Microsoft Visual
Studio\VC98\BIN\link.exe"' failed with exit status 1181

I would like that somebody would let me know when it is fixed.
And if possible, I would like to know about your plans conserning bug
#122395

my E-mail is: sveta@camelot.com
-------------------------------

Thank you,
Just one more thing:
I also tried several times to get registered here in order to be informed
about bugs, but for unknown reason it never works.
That's what I get after I enter all details needed for making a new
account:

The page cannot be displayed 
The page you are looking for is currently unavailable. The Web site might
be experiencing technical difficulties, or you may need to adjust your
browser settings. 

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

Please try the following:

Click the  Refresh button, or try again later.

"
If you typed the page address in the Address bar, make sure that it is
spelled correctly.

To check your connection settings, click the Tools menu, and then click
Internet Options. On the Connections tab, click Settings. The settings
should match those provided by your local area network (LAN) administrator
or Internet service provider (ISP). 
If your Network Administrator has enabled it, Microsoft Windows can examine
your network and automatically discover network connection settings.
If you would like Windows to try and discover them, 
click  Detect Network Settings 
Some sites require 128-bit connection security. Click the Help menu and
then click About Internet Explorer to determine what strength security you
have installed. 
If you are trying to reach a secure site, make sure your Security settings
can support it. Click the Tools menu, and then click Internet Options. On
the Advanced tab, scroll to the Security section and check settings for SSL
2.0, SSL 3.0, TLS 1.0, PCT 1.0. 
Click the  Back button to try another link. 

Cannot find server or DNS Error
Internet Explorer  
"

Why is that???

Thank you,
Svetlana.

my E-mail is: sveta@camelot.com
-------------------------------



Follow-Ups:

Date: 2001-Feb-09 15:55
By: tim_one

Comment:
Assigned to Andrew because he's attracted to hairy installation problems.

Svetlana, sorry you haven't been able to register on SourceForge yet. 
Unfortunately, we don't run or control this site, we're just hosted at
SourceForge.  If your problems persist, you'll have to file a bug with
SourceForge itself:

https://sourceforge.net/bugs/?group_id=1

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131398&group_id=5470


From noreply@sourceforge.net  Sat Feb 10 00:00:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 16:00:07 -0800
Subject: [Python-bugs-list] [Bug #131653] compile.py, mentioned in documentation, unaccessible
Message-ID: <E14RNSR-0006ZN-00@usw-sf-web2.sourceforge.net>

Bug #131653, was updated on 2001-Feb-08 21:56
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : fdrake
Summary: compile.py, mentioned in documentation, unaccessible

Details: In "Extending and Embedding the Python Interpreter" section 3.1
(reference for Windows platform) refers to getting David Ascher's
"compile.py" from http://starship.python.net/crew/da/compile/

This link is dead.  I have tried to follow this up with David Ascher, but
haven't received a response.  So, after a couple of days waiting, I am
submitting it here as a bug in the documentation.

Follow-Ups:

Date: 2001-Feb-09 16:00
By: tim_one

Comment:
Assigned to Fred.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131653&group_id=5470


From noreply@sourceforge.net  Sat Feb 10 00:03:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 16:03:04 -0800
Subject: [Python-bugs-list] [Bug #131774] Architecture-specific config.h is badly named
Message-ID: <E14RNVI-0006aQ-00@usw-sf-web2.sourceforge.net>

Bug #131774, was updated on 2001-Feb-09 13:57
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Submitted by: gramirez
Assigned to : twouters
Summary: Architecture-specific config.h is badly named

Details: If Python is installed with architecture-dependent and
architecture-independent files in separate locations (using --prefix and
--exec-prefix), then config.h is placed in a directory different than
Python.h (and pyport.h and pgenheaders.h, which also #include
"config.h").

If I build a python module which has its own config.h (like pygtk), the
build fails because Python.h #include's the *wrong* config.h. I cannot
easily change the order of the
-I flags when compiling pygtk because autoconf places its flags
(AM_CPPFLAGS) before any CPPFLAGS that I define in the CPPFLAGS environment
variable.

It would be cleaner to follow the glib model which names its installed
arch-specific file "glibconfig.h". We could install config.h as
pythonconfig.h, and have Python.h #include "pythonconfig.h"



Follow-Ups:

Date: 2001-Feb-09 16:03
By: tim_one

Comment:
Assigned to Thomas.  Reassign to someone else if you don't want it!  Guido
said he did want it, but didn't bother assigning it to anyone.  Given that
we delayed "in dict", we have to find some other way to justify giving you
a free alpha release <wink>.

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

Date: 2001-Feb-09 14:10
By: gvanrossum

Comment:
Good idea!  Patch anybody?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131774&group_id=5470


From noreply@sourceforge.net  Fri Feb  9 23:57:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 15:57:31 -0800
Subject: [Python-bugs-list] [Bug #131540] threads and profiler don't work together
Message-ID: <E14RNPv-0006YT-00@usw-sf-web2.sourceforge.net>

Bug #131540, was updated on 2001-Feb-08 07:53
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Submitted by: dbrueck
Assigned to : tim_one
Summary: threads and profiler don't work together

Details: When a new thread is created, it doesn't inherit from the parent
thread the trace and profile functions (sys_tracefunc and sys_profilefunc
in PyThreadState), so multithreaded programs can't easily be profiled. 

This may be by design for safety/complexity sake, but the profiler module
should still find some way to function correctly. A temporary (and
performance-killing) workaround is to modify the standard profiler to hook
into threads to start a new profiler for each new thread, and then merge
the stats from a child thread into the parent's when the child thread
ends.

Here is sample code that exhibits the problem. Stats are printed only for
the main thread because the child thread has no profiling function and
therefore collects no stats:

import threading, profile, time

def yo():
    for j in range(5):
        print j,

def go():
    threading.Thread(target=yo).start()
    time.sleep(1)

profile.run('go()')


Follow-Ups:

Date: 2001-Feb-09 15:57
By: tim_one

Comment:
Assigned to me but reduced the priority.  I'll take a look at it, but have
to suspect it will get reclassified as a Feature Request and moved into PEP
42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131540&group_id=5470


From noreply@sourceforge.net  Sat Feb 10 00:26:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 16:26:31 -0800
Subject: [Python-bugs-list] [Bug #131796] Build error in 2.1a2 due to missing unicodedatabase.c
Message-ID: <E14RNrz-0006Ad-00@usw-sf-web1.sourceforge.net>

Bug #131796, was updated on 2001-Feb-09 16:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: tamisen
Assigned to : nobody
Summary: Build error in 2.1a2 due to missing unicodedatabase.c

Details: I uncommented the line for the unicodedata module in
Modules/Setup:

unicodedata unicodedata.c unicodedatabase.c
                        # static Unicode character database

and then building fails because the unicodedatabase.c file is missing:

make: *** No rule to make target `Modules/unicodedatabase.c', needed by
`Modules/unicodedatabase.o'.  Stop.

Looking inside the Modules directory, I see that it appears the code for
the unicodedata module no longer requires the missing file.

After removing unicodedatabase.c from Modules/Setup, I was able to build
the module successfully.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131796&group_id=5470


From noreply@sourceforge.net  Sat Feb 10 06:11:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 09 Feb 2001 22:11:32 -0800
Subject: [Python-bugs-list] [Bug #131756] [Linux 2.2.19] make test fails CVS HEAD
Message-ID: <E14RTFs-00026h-00@usw-sf-web3.sourceforge.net>

Bug #131756, was updated on 2001-Feb-09 10:32
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : akuchling
Summary: [Linux 2.2.19] make test fails CVS HEAD

Details: I hope this belongs to build category.

For a few weeks I have tracked CVS HEAD, compiling every few
days to test new python features. Up until approximately one
week ago, everything was fine. make distclean, cvs update,
./configure, make, make test then proceed to test new
interpreter.

Recently (last week or so) make test is failing miserably:
./python -c 'import sys ; from distutils.util import get_platform ; print
get_platform()+"-"+sys.version[0:3]' >platform
rm -f ./Lib/test/*.py[co]
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 38, in ?
    import random
  File "/home/gbsadler/cvs/python/dist/src/Lib/random.py", line 76, in ?
    from math import log as _log, exp as _exp, pi as _pi, e as _e
ImportError: No module named math
make: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 38, in ?
    import random
  File "/home/gbsadler/cvs/python/dist/src/Lib/random.py", line 76, in ?
    from math import log as _log, exp as _exp, pi as _pi, e as _e
ImportError: No module named math
make: *** [test] Error 1

I realize the README says not to send the results of make test
but...

gbsadler@xxx:~/cvs/python/dist/src$ ./python Lib/test/regrtest.py
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 38, in ?
    import random
  File "/home/gbsadler/cvs/python/dist/src/Lib/random.py", line 76, in ?
    from math import log as _log, exp as _exp, pi as _pi, e as _e
ImportError: No module named math

Same effect if I just load the new interpreter and try to
import math

I tried to check recent changes to setup.py and/or Makefile.pre.in.
However, only check-in that remotely looks to maybe affect
this from my limited understanding... is a change to Makefile.pre.in
to add oldsharedmods to all: target?

Hope this is worked out, love python here. -)
gbsadler1@lcisp.com
Gordon Sadler

Follow-Ups:

Date: 2001-Feb-09 22:11
By: gbsadler

Comment:
Sometime today between 10AM-4PM CST this has
been resolved in CVS HEAD. It builds/tests fine
now. Not sure who fixed what, but thanks.

Gordon Sadler
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131756&group_id=5470


From noreply@sourceforge.net  Sat Feb 10 08:04:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Feb 2001 00:04:25 -0800
Subject: [Python-bugs-list] [Bug #131796] [Unix] Build error in 2.1a2 due to missing unicodedatabase.c
Message-ID: <E14RV17-0001Hg-00@usw-sf-web2.sourceforge.net>

Bug #131796, was updated on 2001-Feb-09 16:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 7
Submitted by: tamisen
Assigned to : akuchling
Summary: [Unix] Build error in 2.1a2 due to missing unicodedatabase.c

Details: I uncommented the line for the unicodedata module in
Modules/Setup:

unicodedata unicodedata.c unicodedatabase.c
                        # static Unicode character database

and then building fails because the unicodedatabase.c file is missing:

make: *** No rule to make target `Modules/unicodedatabase.c', needed by
`Modules/unicodedatabase.o'.  Stop.

Looking inside the Modules directory, I see that it appears the code for
the unicodedata module no longer requires the missing file.

After removing unicodedatabase.c from Modules/Setup, I was able to build
the module successfully.


Follow-Ups:

Date: 2001-Feb-10 00:04
By: tim_one

Comment:
Assigned to Andrew, bumped priority, changed to Platform-specific, added
[Unix] tag to Summary.  Andrew, take a look?  tamisen is right that
unicodedatabase.c is no longer in the project.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131796&group_id=5470


From noreply@sourceforge.net  Sat Feb 10 08:07:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Feb 2001 00:07:05 -0800
Subject: [Python-bugs-list] [Bug #131824] New std library difflib.py needs docs
Message-ID: <E14RV3h-0001JH-00@usw-sf-web2.sourceforge.net>

Bug #131824, was updated on 2001-Feb-10 00:07
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Submitted by: tim_one
Assigned to : fdrake
Summary: New std library difflib.py needs docs

Details: LaTeXification of the module docstring should be all it requires. 
Unsure where to put it, but "Miscellaneous Services" fits better than most.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131824&group_id=5470


From noreply@sourceforge.net  Sat Feb 10 09:03:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Feb 2001 01:03:27 -0800
Subject: [Python-bugs-list] [Bug #131825] doctest.py needs docs
Message-ID: <E14RVwF-0002Ln-00@usw-sf-web1.sourceforge.net>

Bug #131825, was updated on 2001-Feb-10 01:03
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: tim_one
Assigned to : tim_one
Summary: doctest.py needs docs

Details: I need to write something up for Fred.  The doctest docstrings are
too much info -- need a much quicker intro for the Library Manual, and
point to the docstrings for unusual cases (I personally almost never use
*any* of the fancy stuff!).


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131825&group_id=5470


From noreply@sourceforge.net  Sat Feb 10 12:49:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Feb 2001 04:49:56 -0800
Subject: [Python-bugs-list] [Bug #131796] [Unix] Build error in 2.1a2 due to missing unicodedatabase.c
Message-ID: <E14RZTQ-0004aw-00@usw-sf-web3.sourceforge.net>

Bug #131796, was updated on 2001-Feb-09 16:26
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 7
Submitted by: tamisen
Assigned to : akuchling
Summary: [Unix] Build error in 2.1a2 due to missing unicodedatabase.c

Details: I uncommented the line for the unicodedata module in
Modules/Setup:

unicodedata unicodedata.c unicodedatabase.c
                        # static Unicode character database

and then building fails because the unicodedatabase.c file is missing:

make: *** No rule to make target `Modules/unicodedatabase.c', needed by
`Modules/unicodedatabase.o'.  Stop.

Looking inside the Modules directory, I see that it appears the code for
the unicodedata module no longer requires the missing file.

After removing unicodedatabase.c from Modules/Setup, I was able to build
the module successfully.


Follow-Ups:

Date: 2001-Feb-10 04:49
By: lemburg

Comment:
This Setup.dist in CVS doesn't have this line, so either you forgot
to remove the Modules/Setup file before installing 2.1a2 or
this was already fixed.
-------------------------------------------------------

Date: 2001-Feb-10 00:04
By: tim_one

Comment:
Assigned to Andrew, bumped priority, changed to Platform-specific, added
[Unix] tag to Summary.  Andrew, take a look?  tamisen is right that
unicodedatabase.c is no longer in the project.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131796&group_id=5470


From noreply@sourceforge.net  Sat Feb 10 14:10:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Feb 2001 06:10:01 -0800
Subject: [Python-bugs-list] [Bug #131756] [Linux 2.2.19] make test fails CVS HEAD
Message-ID: <E14Raiv-0004uG-00@usw-sf-web1.sourceforge.net>

Bug #131756, was updated on 2001-Feb-09 10:32
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : akuchling
Summary: [Linux 2.2.19] make test fails CVS HEAD

Details: I hope this belongs to build category.

For a few weeks I have tracked CVS HEAD, compiling every few
days to test new python features. Up until approximately one
week ago, everything was fine. make distclean, cvs update,
./configure, make, make test then proceed to test new
interpreter.

Recently (last week or so) make test is failing miserably:
./python -c 'import sys ; from distutils.util import get_platform ; print
get_platform()+"-"+sys.version[0:3]' >platform
rm -f ./Lib/test/*.py[co]
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 38, in ?
    import random
  File "/home/gbsadler/cvs/python/dist/src/Lib/random.py", line 76, in ?
    from math import log as _log, exp as _exp, pi as _pi, e as _e
ImportError: No module named math
make: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 38, in ?
    import random
  File "/home/gbsadler/cvs/python/dist/src/Lib/random.py", line 76, in ?
    from math import log as _log, exp as _exp, pi as _pi, e as _e
ImportError: No module named math
make: *** [test] Error 1

I realize the README says not to send the results of make test
but...

gbsadler@xxx:~/cvs/python/dist/src$ ./python Lib/test/regrtest.py
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 38, in ?
    import random
  File "/home/gbsadler/cvs/python/dist/src/Lib/random.py", line 76, in ?
    from math import log as _log, exp as _exp, pi as _pi, e as _e
ImportError: No module named math

Same effect if I just load the new interpreter and try to
import math

I tried to check recent changes to setup.py and/or Makefile.pre.in.
However, only check-in that remotely looks to maybe affect
this from my limited understanding... is a change to Makefile.pre.in
to add oldsharedmods to all: target?

Hope this is worked out, love python here. -)
gbsadler1@lcisp.com
Gordon Sadler

Follow-Ups:

Date: 2001-Feb-10 06:10
By: gvanrossum

Comment:
Fixed itself -- or it was something in the user env.  Hard to say.
-------------------------------------------------------

Date: 2001-Feb-09 22:11
By: gbsadler

Comment:
Sometime today between 10AM-4PM CST this has
been resolved in CVS HEAD. It builds/tests fine
now. Not sure who fixed what, but thanks.

Gordon Sadler
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131756&group_id=5470


From noreply@sourceforge.net  Sat Feb 10 20:47:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Feb 2001 12:47:00 -0800
Subject: [Python-bugs-list] [Bug #131439] python and Python interfaces should use cc -G for so's
Message-ID: <E14Rgv6-00066n-00@usw-sf-web2.sourceforge.net>

Bug #131439, was updated on 2001-Feb-07 10:52
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: ler
Assigned to : nascheme
Summary: python and Python interfaces should use cc -G for so's

Details: the Python build environment should use cc -G for it's shared
libs.  This is true at *LEAST* on UnixWare.  The ld man page calls this
out. 

The PostgreSQL interface build had to be modified because of this. 

If you need a shell account on a UnixWare 7 box, I can arrange same. 

LER


Follow-Ups:

Date: 2001-Feb-10 12:46
By: nascheme

Comment:
What does "uname -u" say for UnixWare?
-------------------------------------------------------

Date: 2001-Feb-08 09:23
By: akuchling

Comment:
Assigning to Neil.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131439&group_id=5470


From noreply@sourceforge.net  Sat Feb 10 21:07:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Feb 2001 13:07:08 -0800
Subject: [Python-bugs-list] [Bug #131222] Python-2.1a2: HP make continiously runs the configure script
Message-ID: <E14RhEa-0006EQ-00@usw-sf-web2.sourceforge.net>

Bug #131222, was updated on 2001-Feb-05 23:50
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nascheme
Summary: Python-2.1a2: HP make continiously runs the configure script

Details: Source:		Python-2.1a2
OS:		HP-UX 11.00

Commands:
	./configure  (or ./configure --with-threads=no)
	make

Details:
	Once make finishes compiling Python/dynload_hpux.c, it runs the configure
script, which will continue to run over and over.

.....
        gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include
-DHAVE_CONFIG_H -o Python/traceback.o Python/traceback.c
        gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include
-DHAVE_CONFIG_H -o Python/getopt.o Python/getopt.c
        gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include
-DHAVE_CONFIG_H -o Python/dynload_hpux.o Python/dynload_hpux.c
        if test -f config.status; \
        then /bin/sh config.status --recheck; \
             /bin/sh config.status; \
        else /bin/sh ./configure ; \
        fi
running /bin/sh ./configure  --prefix=/opt/python2 --with-threads=no
--no-create --no-recursion
loading cache ./config.cache
checking MACHDEP... hp-uxB
checking for --without-gcc... no
checking for --with-cxx=<compiler>... no
checking for c++... (cached) c++

....


Follow-Ups:

Date: 2001-Feb-10 13:07
By: nascheme

Comment:
Make seems to think that config.status is older than
configure, even after re-running configure.  I don't know
how that's possible.  configure recreates config.status
when it runs.  It would be helpful if you could give me
all the output from make for a complete cycle.

You could try adding "touch config.status" at the very
end of the config.status target in the makefile and see
if that helps.
-------------------------------------------------------

Date: 2001-Feb-08 09:22
By: akuchling

Comment:
Reassigning to Neil, and reclassifying as a build problem.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131222&group_id=5470


From noreply@sourceforge.net  Sun Feb 11 00:41:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Feb 2001 16:41:56 -0800
Subject: [Python-bugs-list] [Bug #131439] python and Python interfaces should use cc -G for so's
Message-ID: <E14RkaS-0002Ci-00@usw-sf-web1.sourceforge.net>

Bug #131439, was updated on 2001-Feb-07 10:52
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: ler
Assigned to : nascheme
Summary: python and Python interfaces should use cc -G for so's

Details: the Python build environment should use cc -G for it's shared
libs.  This is true at *LEAST* on UnixWare.  The ld man page calls this
out. 

The PostgreSQL interface build had to be modified because of this. 

If you need a shell account on a UnixWare 7 box, I can arrange same. 

LER


Follow-Ups:

Date: 2001-Feb-10 16:41
By: ler

Comment:
uname -u is invalid.  

$ uname -u
UX:uname: ERROR: Illegal option -- u
UX:uname: TO FIX: Usage:
        uname parameter_name
        uname -f
        uname [-acdilmnprsvAX]
        uname [-S system name]
$ uname -a
UnixWare lerlaptop 5 7.1.1 i386 x86at SCO UNIX_SVR5
$ uname -s
UnixWare
$ uname -r
5
$ uname -v
7.1.1
$ uname -a
UnixWare lerlaptop 5 7.1.1 i386 x86at SCO UNIX_SVR5
$ 

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

Date: 2001-Feb-10 12:46
By: nascheme

Comment:
What does "uname -u" say for UnixWare?
-------------------------------------------------------

Date: 2001-Feb-08 09:23
By: akuchling

Comment:
Assigning to Neil.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131439&group_id=5470


From noreply@sourceforge.net  Sun Feb 11 04:03:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Feb 2001 20:03:58 -0800
Subject: [Python-bugs-list] [Bug #131239] -x flag is ignored on non pyc files
Message-ID: <E14Rnjy-00021p-00@usw-sf-web3.sourceforge.net>

Bug #131239, was updated on 2001-Feb-06 02:30
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 8
Submitted by: mpmak
Assigned to : gvanrossum
Summary: -x flag is ignored on non pyc files

Details: 
simple script x.bat will raise syntax error in line 1
@python -x "%~f0" %* & goto :EOF
print 'ok'

maybe_pyc_file in pythonrun.c does not save/restore file position when
reading non pyc file which was given as argument on command line.


Follow-Ups:

Date: 2001-Feb-10 20:03
By: tim_one

Comment:
Boosted priority, cuz -x must be broken everywhere.  Unclear how to fix
it.

Saving/restoring the file pointer in maybe_pyc_file won't do the trick,
because in case of -x an ungetc() is used to push the first newline back
onto the stream; an ftell/fseek pair would blow that away, reintroducing
the bug (off-by-one line numbers in tracebacks) that ungetc() was
introduced to fix.  fseek()ing to "one before" the current fp position
isn't any good either, because the input file was opened in text mode, and
arithmetic on ftell() results doesn't work x-platform due to line-end
translations.  (Strictly speaking, the stream position is undefined after
an ungetc() for streams opened in text mode.)

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

Date: 2001-Feb-09 15:48
By: tim_one

Comment:
Assigned to Guido.  Guido, can you reproduce?  This requires cmd.exe, not
the command.com Win9X uses for a shell (i.e., I can't try it; but you can
under your Win2000).  Hmm.  Under Win98SE, I can put this in x.bat and get
(almost certainly) the same problem (via running x.bat):

python -x x.bat
print "hi"

Nothing special about .bat files!  Have to suspect -x is plain busted.
-------------------------------------------------------

Date: 2001-Feb-09 15:37
By: jhylton

Comment:
No clue what the .bat file is trying to do.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131239&group_id=5470


From noreply@sourceforge.net  Sun Feb 11 04:18:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Feb 2001 20:18:30 -0800
Subject: [Python-bugs-list] [Bug #131480] __test__() should auto-exec at compile time
Message-ID: <E14Rny2-00027e-00@usw-sf-web3.sourceforge.net>

Bug #131480, was updated on 2001-Feb-07 18:44
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Wont Fix
Bug Group: Feature Request
Priority: 5
Submitted by: justinshaw
Assigned to : jhylton
Summary: __test__() should auto-exec at compile time

Details: We can make unit testing as simple as writing the test code!
Everyone agrees that unit tests are worth while.  Python does a great job
removing tedium from the job of the programmer.  Unit test should run
automatically.  Here's a method everyone can agree to:

Have the compiler check each module for a funtion with the special name
'__test__' that takes no arguments.  If it finds it it calls it.

The problem of unit testing divides esiliy into two pieces: How to create
the code and how to execute the code.  There are many options in creating
the code but I have never seen any nice solutions to run the code
automatically
"if __name__ == '__main__':"
 doesn't count since you have to do somthing special to call the code i.e.
run it as a script.  There are of course ways to run the test code
automatically but the ways I have figured out run it on every import (way
too often especially for long tests).  I imagine there is a way to check to
see if the module is loaded from a .pyc file and execute test code
accouringly but this seems a bit kludgy.  Here are the benifits of compile
time auto-execution:

- Compatible with every testing framework.
- Called always and only when it needs to be executed.
- So simple even micro projects 'scripts' can take advantage

Disadvantages:
- Another special name, '__test__'
- If there are more please tell me!

I looked around the source-code and think I see the location where we can
do this.  It's would be a piece of cake and the advantages far outway the
disadvantages.  If I get some support I'd love to incorporate the fix.

Justin Shaw
thomas.j.shaw@aero.org

Follow-Ups:

Date: 2001-Feb-10 20:18
By: justinshaw

Comment:
jhylton,
Consider the synergistic effect of the niceties python offers.  Automatic
compilation, integrated documentation, and standardized coding style to
name a few.  These are all things that can be completed externally in a
trivial manner, yet their combined effect is the reason we love python
(aside from incredibly simple and powerful object orientation).

I certainly have much to learn about python and unit testing.  Maybe I have
completely missed the boat with unit testing.  For team projects it clearly
makes sense to set up a unit-testing machine with test running software. 
But in my particular case, and I suspect many others', I maintain many self
testing libraries with application scripts, not full blown applications.  I
work alone without CVS support and am constantly updating and modifying the
libraries.  I enjoy the confidence unit testing gives me to make these
mods.  I don't expend any brain cycles on whether unit testing is current
because they always run on every import*.  I am an ardent supporter of
automation where it makes sense and I'm sure you can come up with many
instances where it does not make sense.  In those cases you are by no means
forced to automatically execute unit tests.

If your mechanism meets the following criteria I take back all I have said
and will eagerly download it:
1. The standard // Remember documentation before javadoc?
2. Portable
3. Tests run only when the code is updated
4. One time implimentation

(I'd settle for 2, 3, and 4.)

Thank you for your timely response, I hope you'll reconsider
Justin Shaw
Thomas.J.Shaw@aero.org
 
* Overkill I realize hence the feature request
-------------------------------------------------------

Date: 2001-Feb-09 15:35
By: jhylton

Comment:
I don't agree that unit tests should run automatically.  Nor do I think
adding magic to the language to support unit tests is necessary when it is
trivial to add some external mechanism.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131480&group_id=5470


From noreply@sourceforge.net  Sun Feb 11 04:37:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 10 Feb 2001 20:37:52 -0800
Subject: [Python-bugs-list] [Bug #131239] -x flag is ignored on non pyc files
Message-ID: <E14RoGm-0002EH-00@usw-sf-web3.sourceforge.net>

Bug #131239, was updated on 2001-Feb-06 02:30
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 8
Submitted by: mpmak
Assigned to : tim_one
Summary: -x flag is ignored on non pyc files

Details: 
simple script x.bat will raise syntax error in line 1
@python -x "%~f0" %* & goto :EOF
print 'ok'

maybe_pyc_file in pythonrun.c does not save/restore file position when
reading non pyc file which was given as argument on command line.


Follow-Ups:

Date: 2001-Feb-10 20:37
By: tim_one

Comment:
Closed and Fixed, reassigned to me.  Ugly but std-conforming fix checked in
to pythonrun.c rev 2.122.

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

Date: 2001-Feb-10 20:03
By: tim_one

Comment:
Boosted priority, cuz -x must be broken everywhere.  Unclear how to fix
it.

Saving/restoring the file pointer in maybe_pyc_file won't do the trick,
because in case of -x an ungetc() is used to push the first newline back
onto the stream; an ftell/fseek pair would blow that away, reintroducing
the bug (off-by-one line numbers in tracebacks) that ungetc() was
introduced to fix.  fseek()ing to "one before" the current fp position
isn't any good either, because the input file was opened in text mode, and
arithmetic on ftell() results doesn't work x-platform due to line-end
translations.  (Strictly speaking, the stream position is undefined after
an ungetc() for streams opened in text mode.)

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

Date: 2001-Feb-09 15:48
By: tim_one

Comment:
Assigned to Guido.  Guido, can you reproduce?  This requires cmd.exe, not
the command.com Win9X uses for a shell (i.e., I can't try it; but you can
under your Win2000).  Hmm.  Under Win98SE, I can put this in x.bat and get
(almost certainly) the same problem (via running x.bat):

python -x x.bat
print "hi"

Nothing special about .bat files!  Have to suspect -x is plain busted.
-------------------------------------------------------

Date: 2001-Feb-09 15:37
By: jhylton

Comment:
No clue what the .bat file is trying to do.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131239&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 13:21:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 05:21:57 -0800
Subject: [Python-bugs-list] [Bug #131996] wrong argument list for "def _cmp(...)" in filecmp.py
Message-ID: <E14SIvV-0006yy-00@usw-sf-web3.sourceforge.net>

Bug #131996, was updated on 2001-Feb-12 05:21
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: wrong argument list for "def _cmp(...)" in filecmp.py

Details: to whom it may concern,

in the file filecmp.py please check the method _cmp(...) - I try to use
"dircmp(dir_a, dir_b) and get the following messages:

Traceback (most recent call last):
  File "\users\lib\filecmp.py", line 328, in ?
    demo()
  File "\users\lib\filecmp.py", line 323, in demo
    dd.report_full_closure()
  File "\users\lib\filecmp.py", line 264, in report_full_closure
    self.report()
  File "\users\lib\filecmp.py", line 241, in report
    if self.same_files:
  File "\users\lib\filecmp.py", line 147, in __getattr__
    self.phase3()
  File "\users\lib\filecmp.py", line 214, in phase3
    xx = cmpfiles(self.left, self.right, self.common_files)
  File "\users\lib\filecmp.py", line 288, in cmpfiles
    res[_cmp(ax, bx, shallow, use_statcache)].append(x)
TypeError: too many arguments; expected 2, got 4

Please correct the method _cmp(...)

thanks


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131996&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 15:18:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 07:18:40 -0800
Subject: [Python-bugs-list] [Bug #132000] New robotparser fails for non-HTTP schemes
Message-ID: <E14SKkS-0006IE-00@usw-sf-web2.sourceforge.net>

Bug #132000, was updated on 2001-Feb-12 07:18
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: fdrake
Assigned to : montanaro
Summary: New robotparser fails for non-HTTP schemes

Details: The new robotparser module fails for non-HTTP URLs where the old
one did not.  In particular, file: URLs cause an exception to be raised
(socket.error: (111, 'Connection refused')) where the old robotparser did
not fail.

This is due, at least in part, by the current code using httplib directly
rather than using urllib for flexibility.  The code should be changed
accordingly.

A good test case for this is running webchecker on a local tree of HTML
files.  I currently get the exception:

cj42289-a(.../Doc/html); python ../../Tools/webchecker/webchecker.py -x
file://`pwd`/api/
webchecker version 1.22
Traceback (most recent call last):
  File "../../Tools/webchecker/webchecker.py", line 824, in ?
    main()
  File "../../Tools/webchecker/webchecker.py", line 205, in main
    c.addroot(arg)
  File "../../Tools/webchecker/webchecker.py", line 324, in addroot
    self.addrobot(root)
  File "../../Tools/webchecker/webchecker.py", line 337, in addrobot
    rp.read()
  File "/usr/local/lib/python2.1/robotparser.py", line 46, in read
    connection.putrequest("GET", self.path)
  File "/usr/local/lib/python2.1/httplib.py", line 426, in putrequest
    self.send(str)
  File "/usr/local/lib/python2.1/httplib.py", line 368, in send
    self.connect()
  File "/usr/local/lib/python2.1/httplib.py", line 352, in connect
    self.sock.connect((self.host, self.port))
socket.error: (111, 'Connection refused')

Assigned to Skip since he's the robots.txt guru.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132000&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 15:32:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 07:32:16 -0800
Subject: [Python-bugs-list] [Bug #131725] Making documentation requires Python 2.0+
Message-ID: <E14SKxc-0006me-00@usw-sf-web1.sourceforge.net>

Bug #131725, was updated on 2001-Feb-09 07:07
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: jnelson
Assigned to : fdrake
Summary: Making documentation requires Python 2.0+

Details: The python scripts which come with the Python2.1a2 
tarball require features not available in Python 1.5.2

Also, the scripts use /usr/bin/env python
instead of 
/usr/bin/env python{1.6,2.0,2.1} etc...

A patch is included.

diff -u -r Python-2.1a2/Doc/tools/mkhowto
foo/Python-2.1a2/Doc/tools/mkhowto
--- Python-2.1a2/Doc/tools/mkhowto	Tue Jan 30 16:30:01 2001
+++ foo/Python-2.1a2/Doc/tools/mkhowto	Fri Feb  9 08:25:42 2001
@@ -297,7 +297,7 @@
             # let the doctype-specific handler do some intermediate
work:
             #
             self.run("%s %s" % (binary, self.doc))
-            self.latex_runs += 1
+            self.latex_runs = self.latex_runs + 1
             if os.path.isfile("mod%s.idx" % self.doc):
                 self.run("%s -s %s mod%s.idx"
                          % (MAKEINDEX_BINARY, ISTFILE, self.doc))
@@ -319,7 +319,7 @@
         if self.use_bibtex:
             self.run("%s %s" % (BIBTEX_BINARY, self.doc))
         self.run("%s %s" % (binary, self.doc))
-        self.latex_runs += 1
+        self.latex_runs = self.latex_runs + 1
 
     def process_synopsis_files(self):
         synopsis_files = glob.glob(self.doc + "*.syn")
diff -u -r Python-2.1a2/Doc/tools/mkmodindex
foo/Python-2.1a2/Doc/tools/mkmodindex
--- Python-2.1a2/Doc/tools/mkmodindex	Tue Nov 28 10:20:50 2000
+++ foo/Python-2.1a2/Doc/tools/mkmodindex	Fri Feb  9 08:27:30 2001
@@ -117,9 +117,9 @@
     html = string.join(parts, '')
     program = os.path.basename(sys.argv[0])
     fp = options.get_output_file()
-    print >>fp, html.rstrip()
+    fp.write( html.rstrip() + "\n" )
     if options.outputfile == "-":
-        print >>sys.stderr, "%s: %d index nodes" % (program, num_nodes)
+        sys.stderr.write("%s: %d index nodes\n" % (program, num_nodes))
     else:
         print
         print "%s: %d index nodes" % (program, num_nodes)
diff -u -r Python-2.1a2/Doc/tools/support.py
foo/Python-2.1a2/Doc/tools/support.py
--- Python-2.1a2/Doc/tools/support.py	Thu Oct  5 00:20:55 2000
+++ foo/Python-2.1a2/Doc/tools/support.py	Fri Feb  9 08:32:50 2001
@@ -9,6 +9,7 @@
 
 import getopt
 import sys
+import string
 
 
 class Options:
@@ -37,9 +38,9 @@
 
     def add_args(self, short=None, long=None):
         if short:
-            self.__short_args += short
+            self.__short_args = self.__short_args + short
         if long:
-            self.__long_args += long
+            self.__long_args = self.__long_args + long
 
     def parse(self, args):
         try:
@@ -49,10 +50,10 @@
             sys.stdout = sys.stderr
             self.usage()
             sys.exit(2)
-        self.args += args
+        self.args = self.args + args
         for opt, val in opts:
             if opt in ("-a", "--address"):
-                val = val.strip()
+                val = string.strip(val)
                 if val:
                     val = "<address>\n%s\n</address>\n" % val
                     self.variables["address"] = val


Follow-Ups:

Date: 2001-Feb-12 07:32
By: fdrake

Comment:
Checked in a very slightly modified version of the patch as
Doc/tools/mkhowto revision 1.22, Doc/tools/mkmodindex revision 1.10, and
Doc/tools/support.py revision 1.3.

Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131725&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 16:25:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 08:25:08 -0800
Subject: [Python-bugs-list] [Bug #131725] Making documentation requires Python 2.0+
Message-ID: <E14SLmm-0006pd-00@usw-sf-web2.sourceforge.net>

Bug #131725, was updated on 2001-Feb-09 07:07
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: jnelson
Assigned to : fdrake
Summary: Making documentation requires Python 2.0+

Details: The python scripts which come with the Python2.1a2 
tarball require features not available in Python 1.5.2

Also, the scripts use /usr/bin/env python
instead of 
/usr/bin/env python{1.6,2.0,2.1} etc...

A patch is included.

diff -u -r Python-2.1a2/Doc/tools/mkhowto
foo/Python-2.1a2/Doc/tools/mkhowto
--- Python-2.1a2/Doc/tools/mkhowto	Tue Jan 30 16:30:01 2001
+++ foo/Python-2.1a2/Doc/tools/mkhowto	Fri Feb  9 08:25:42 2001
@@ -297,7 +297,7 @@
             # let the doctype-specific handler do some intermediate
work:
             #
             self.run("%s %s" % (binary, self.doc))
-            self.latex_runs += 1
+            self.latex_runs = self.latex_runs + 1
             if os.path.isfile("mod%s.idx" % self.doc):
                 self.run("%s -s %s mod%s.idx"
                          % (MAKEINDEX_BINARY, ISTFILE, self.doc))
@@ -319,7 +319,7 @@
         if self.use_bibtex:
             self.run("%s %s" % (BIBTEX_BINARY, self.doc))
         self.run("%s %s" % (binary, self.doc))
-        self.latex_runs += 1
+        self.latex_runs = self.latex_runs + 1
 
     def process_synopsis_files(self):
         synopsis_files = glob.glob(self.doc + "*.syn")
diff -u -r Python-2.1a2/Doc/tools/mkmodindex
foo/Python-2.1a2/Doc/tools/mkmodindex
--- Python-2.1a2/Doc/tools/mkmodindex	Tue Nov 28 10:20:50 2000
+++ foo/Python-2.1a2/Doc/tools/mkmodindex	Fri Feb  9 08:27:30 2001
@@ -117,9 +117,9 @@
     html = string.join(parts, '')
     program = os.path.basename(sys.argv[0])
     fp = options.get_output_file()
-    print >>fp, html.rstrip()
+    fp.write( html.rstrip() + "\n" )
     if options.outputfile == "-":
-        print >>sys.stderr, "%s: %d index nodes" % (program, num_nodes)
+        sys.stderr.write("%s: %d index nodes\n" % (program, num_nodes))
     else:
         print
         print "%s: %d index nodes" % (program, num_nodes)
diff -u -r Python-2.1a2/Doc/tools/support.py
foo/Python-2.1a2/Doc/tools/support.py
--- Python-2.1a2/Doc/tools/support.py	Thu Oct  5 00:20:55 2000
+++ foo/Python-2.1a2/Doc/tools/support.py	Fri Feb  9 08:32:50 2001
@@ -9,6 +9,7 @@
 
 import getopt
 import sys
+import string
 
 
 class Options:
@@ -37,9 +38,9 @@
 
     def add_args(self, short=None, long=None):
         if short:
-            self.__short_args += short
+            self.__short_args = self.__short_args + short
         if long:
-            self.__long_args += long
+            self.__long_args = self.__long_args + long
 
     def parse(self, args):
         try:
@@ -49,10 +50,10 @@
             sys.stdout = sys.stderr
             self.usage()
             sys.exit(2)
-        self.args += args
+        self.args = self.args + args
         for opt, val in opts:
             if opt in ("-a", "--address"):
-                val = val.strip()
+                val = string.strip(val)
                 if val:
                     val = "<address>\n%s\n</address>\n" % val
                     self.variables["address"] = val


Follow-Ups:

Date: 2001-Feb-12 08:25
By: jnelson

Comment:
Here's more to make it finish under 1.5.2:
Sorry for the horrible formatting.
Index: dist/src/Doc/tools/mkackshtml
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/tools/mkackshtml,v
retrieving revision 1.1
diff -u -r1.1 mkackshtml
--- dist/src/Doc/tools/mkackshtml       2000/10/05 05:15:29     1.1
+++ dist/src/Doc/tools/mkackshtml       2001/02/12 16:16:47
@@ -3,15 +3,15 @@
 
 import support
 import sys
+import string
 
-
 def collect(fp):
     names = []
     while 1:
         line = fp.readline()
         if not line:
             break
-        line = line.strip()
+        line = string.strip(line)
         if line:
             names.append(line)
         else:
@@ -26,22 +26,25 @@
     options.parse(sys.argv[1:])
     names = collect(sys.stdin)
     percol = (len(names) + options.columns - 1) / options.columns
-    colnums = [percol*i for i in range(options.columns)]
+    colnums = []
+    for i in range(options.columns):
+      colnums.append(percol*i)
+#    colnums = [percol*i for i in range(options.columns)]
     fp = options.get_output_file()
-    print >>fp, options.get_header().rstrip()
-    print >>fp, THANKS
-    print >>fp, '<table width="100%" align="center">'
+    fp.write(string.rstrip(options.get_header()) + "\n")
+    fp.write(THANKS + "\n")
+    fp.write('<table width="100%" align="center">\n')
     for i in range(percol):
-        print >>fp, "  <tr>"
+        fp.write("  <tr>\n")
         for j in colnums:
             try:
-                print >>fp, "    <td>%s</td>" % names[i + j]
+                fp.write("    <td>%s</td>\n" % names[i + j])
             except IndexError:
-                print >>fp, "    <td>&nbsp;</td>"
-        print >>fp, "  </tr>"
-    print >>fp, options.get_footer().rstrip()
-
+                fp.write("    <td>&nbsp;</td>\n")
+        fp.write("  </tr>\n")
+    fp.write("</table>\n")
+    fp.write(string.rstrip(options.get_footer()) + "\n")
+    fp.close()
 
 THANKS = '''\
 
Index: dist/src/Doc/tools/mkmodindex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/tools/mkmodindex,v
retrieving revision 1.10
diff -u -r1.10 mkmodindex
--- dist/src/Doc/tools/mkmodindex       2001/02/12 15:30:22     1.10
+++ dist/src/Doc/tools/mkmodindex       2001/02/12 16:16:47
@@ -52,8 +52,8 @@
     annotation = ""
 
     def __init__(self, link, str, seqno):
-        parts = str.split(None, 1)
-        if parts[0].endswith("</tt>"):
+        parts = string.split(str, None, 1)
+        if parts[0][-5] == "</tt>":
             self.modname = parts[0][:-5]
         else:
             self.modname = parts[0]

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

Date: 2001-Feb-12 07:32
By: fdrake

Comment:
Checked in a very slightly modified version of the patch as
Doc/tools/mkhowto revision 1.22, Doc/tools/mkmodindex revision 1.10, and
Doc/tools/support.py revision 1.3.

Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131725&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 16:28:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 08:28:14 -0800
Subject: [Python-bugs-list] [Bug #132005] Making documentation requires Python 2.0+ (II)
Message-ID: <E14SLpm-0006r6-00@usw-sf-web2.sourceforge.net>

Bug #132005, was updated on 2001-Feb-12 08:28
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: jnelson
Assigned to : nobody
Summary: Making documentation requires Python 2.0+ (II)

Details: Additional patching for #131725.
This should complete the patching necessary to make
it work under 1.5.2

Index: dist/src/Doc/tools/mkackshtml
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/tools/mkackshtml,v
retrieving revision 1.1
diff -u -r1.1 mkackshtml
--- dist/src/Doc/tools/mkackshtml       2000/10/05 05:15:29     1.1
+++ dist/src/Doc/tools/mkackshtml       2001/02/12 16:16:47
@@ -3,15 +3,15 @@
 
 import support
 import sys
+import string
 
-
 def collect(fp):
     names = []
     while 1:
         line = fp.readline()
         if not line:
             break
-        line = line.strip()
+        line = string.strip(line)
         if line:
             names.append(line)
         else:
@@ -26,22 +26,25 @@
     options.parse(sys.argv[1:])
     names = collect(sys.stdin)
     percol = (len(names) + options.columns - 1) / options.columns
-    colnums = [percol*i for i in range(options.columns)]
+    colnums = []
+    for i in range(options.columns):
+      colnums.append(percol*i)
+#    colnums = [percol*i for i in range(options.columns)]
     fp = options.get_output_file()
-    print >>fp, options.get_header().rstrip()
-    print >>fp, THANKS
-    print >>fp, '<table width="100%" align="center">'
+    fp.write(string.rstrip(options.get_header()) + "\n")
+    fp.write(THANKS + "\n")
+    fp.write('<table width="100%" align="center">\n')
     for i in range(percol):
-        print >>fp, "  <tr>"
+        fp.write("  <tr>\n")
         for j in colnums:
             try:
-                print >>fp, "    <td>%s</td>" % names[i + j]
+                fp.write("    <td>%s</td>\n" % names[i + j])
             except IndexError:
-                print >>fp, "    <td>&nbsp;</td>"
-        print >>fp, "  </tr>"
-    print >>fp, "</table>"
-    print >>fp, options.get_footer().rstrip()
-
+                fp.write("    <td>&nbsp;</td>\n")
+        fp.write("  </tr>\n")
+    fp.write("</table>\n")
+    fp.write(string.rstrip(options.get_footer()) + "\n")
+    fp.close()
 
 THANKS = '''\
 
Index: dist/src/Doc/tools/mkmodindex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/tools/mkmodindex,v
retrieving revision 1.10
diff -u -r1.10 mkmodindex
--- dist/src/Doc/tools/mkmodindex       2001/02/12 15:30:22     1.10
+++ dist/src/Doc/tools/mkmodindex       2001/02/12 16:16:47
@@ -52,8 +52,8 @@
     annotation = ""
 
     def __init__(self, link, str, seqno):
-        parts = str.split(None, 1)
-        if parts[0].endswith("</tt>"):
+        parts = string.split(str, None, 1)
+        if parts[0][-5] == "</tt>":
             self.modname = parts[0][:-5]
         else:
             self.modname = parts[0]


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132005&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 16:39:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 08:39:57 -0800
Subject: [Python-bugs-list] [Bug #131725] Making documentation requires Python 2.0+
Message-ID: <E14SM17-0007Si-00@usw-sf-web1.sourceforge.net>

Bug #131725, was updated on 2001-Feb-09 07:07
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: jnelson
Assigned to : fdrake
Summary: Making documentation requires Python 2.0+

Details: The python scripts which come with the Python2.1a2 
tarball require features not available in Python 1.5.2

Also, the scripts use /usr/bin/env python
instead of 
/usr/bin/env python{1.6,2.0,2.1} etc...

A patch is included.

diff -u -r Python-2.1a2/Doc/tools/mkhowto
foo/Python-2.1a2/Doc/tools/mkhowto
--- Python-2.1a2/Doc/tools/mkhowto	Tue Jan 30 16:30:01 2001
+++ foo/Python-2.1a2/Doc/tools/mkhowto	Fri Feb  9 08:25:42 2001
@@ -297,7 +297,7 @@
             # let the doctype-specific handler do some intermediate
work:
             #
             self.run("%s %s" % (binary, self.doc))
-            self.latex_runs += 1
+            self.latex_runs = self.latex_runs + 1
             if os.path.isfile("mod%s.idx" % self.doc):
                 self.run("%s -s %s mod%s.idx"
                          % (MAKEINDEX_BINARY, ISTFILE, self.doc))
@@ -319,7 +319,7 @@
         if self.use_bibtex:
             self.run("%s %s" % (BIBTEX_BINARY, self.doc))
         self.run("%s %s" % (binary, self.doc))
-        self.latex_runs += 1
+        self.latex_runs = self.latex_runs + 1
 
     def process_synopsis_files(self):
         synopsis_files = glob.glob(self.doc + "*.syn")
diff -u -r Python-2.1a2/Doc/tools/mkmodindex
foo/Python-2.1a2/Doc/tools/mkmodindex
--- Python-2.1a2/Doc/tools/mkmodindex	Tue Nov 28 10:20:50 2000
+++ foo/Python-2.1a2/Doc/tools/mkmodindex	Fri Feb  9 08:27:30 2001
@@ -117,9 +117,9 @@
     html = string.join(parts, '')
     program = os.path.basename(sys.argv[0])
     fp = options.get_output_file()
-    print >>fp, html.rstrip()
+    fp.write( html.rstrip() + "\n" )
     if options.outputfile == "-":
-        print >>sys.stderr, "%s: %d index nodes" % (program, num_nodes)
+        sys.stderr.write("%s: %d index nodes\n" % (program, num_nodes))
     else:
         print
         print "%s: %d index nodes" % (program, num_nodes)
diff -u -r Python-2.1a2/Doc/tools/support.py
foo/Python-2.1a2/Doc/tools/support.py
--- Python-2.1a2/Doc/tools/support.py	Thu Oct  5 00:20:55 2000
+++ foo/Python-2.1a2/Doc/tools/support.py	Fri Feb  9 08:32:50 2001
@@ -9,6 +9,7 @@
 
 import getopt
 import sys
+import string
 
 
 class Options:
@@ -37,9 +38,9 @@
 
     def add_args(self, short=None, long=None):
         if short:
-            self.__short_args += short
+            self.__short_args = self.__short_args + short
         if long:
-            self.__long_args += long
+            self.__long_args = self.__long_args + long
 
     def parse(self, args):
         try:
@@ -49,10 +50,10 @@
             sys.stdout = sys.stderr
             self.usage()
             sys.exit(2)
-        self.args += args
+        self.args = self.args + args
         for opt, val in opts:
             if opt in ("-a", "--address"):
-                val = val.strip()
+                val = string.strip(val)
                 if val:
                     val = "<address>\n%s\n</address>\n" % val
                     self.variables["address"] = val


Follow-Ups:

Date: 2001-Feb-12 08:39
By: jnelson

Comment:
I probably did a "bad", but I made a bug 132005,
and it contains the addition I made above.

I didn't know how to make this bug "open" 
again.


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

Date: 2001-Feb-12 08:25
By: jnelson

Comment:
Here's more to make it finish under 1.5.2:
Sorry for the horrible formatting.
Index: dist/src/Doc/tools/mkackshtml
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/tools/mkackshtml,v
retrieving revision 1.1
diff -u -r1.1 mkackshtml
--- dist/src/Doc/tools/mkackshtml       2000/10/05 05:15:29     1.1
+++ dist/src/Doc/tools/mkackshtml       2001/02/12 16:16:47
@@ -3,15 +3,15 @@
 
 import support
 import sys
+import string
 
-
 def collect(fp):
     names = []
     while 1:
         line = fp.readline()
         if not line:
             break
-        line = line.strip()
+        line = string.strip(line)
         if line:
             names.append(line)
         else:
@@ -26,22 +26,25 @@
     options.parse(sys.argv[1:])
     names = collect(sys.stdin)
     percol = (len(names) + options.columns - 1) / options.columns
-    colnums = [percol*i for i in range(options.columns)]
+    colnums = []
+    for i in range(options.columns):
+      colnums.append(percol*i)
+#    colnums = [percol*i for i in range(options.columns)]
     fp = options.get_output_file()
-    print >>fp, options.get_header().rstrip()
-    print >>fp, THANKS
-    print >>fp, '<table width="100%" align="center">'
+    fp.write(string.rstrip(options.get_header()) + "\n")
+    fp.write(THANKS + "\n")
+    fp.write('<table width="100%" align="center">\n')
     for i in range(percol):
-        print >>fp, "  <tr>"
+        fp.write("  <tr>\n")
         for j in colnums:
             try:
-                print >>fp, "    <td>%s</td>" % names[i + j]
+                fp.write("    <td>%s</td>\n" % names[i + j])
             except IndexError:
-                print >>fp, "    <td>&nbsp;</td>"
-        print >>fp, "  </tr>"
-    print >>fp, options.get_footer().rstrip()
-
+                fp.write("    <td>&nbsp;</td>\n")
+        fp.write("  </tr>\n")
+    fp.write("</table>\n")
+    fp.write(string.rstrip(options.get_footer()) + "\n")
+    fp.close()
 
 THANKS = '''\
 
Index: dist/src/Doc/tools/mkmodindex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/tools/mkmodindex,v
retrieving revision 1.10
diff -u -r1.10 mkmodindex
--- dist/src/Doc/tools/mkmodindex       2001/02/12 15:30:22     1.10
+++ dist/src/Doc/tools/mkmodindex       2001/02/12 16:16:47
@@ -52,8 +52,8 @@
     annotation = ""
 
     def __init__(self, link, str, seqno):
-        parts = str.split(None, 1)
-        if parts[0].endswith("</tt>"):
+        parts = string.split(str, None, 1)
+        if parts[0][-5] == "</tt>":
             self.modname = parts[0][:-5]
         else:
             self.modname = parts[0]

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

Date: 2001-Feb-12 07:32
By: fdrake

Comment:
Checked in a very slightly modified version of the patch as
Doc/tools/mkhowto revision 1.22, Doc/tools/mkmodindex revision 1.10, and
Doc/tools/support.py revision 1.3.

Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131725&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 16:45:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 08:45:02 -0800
Subject: [Python-bugs-list] [Bug #132008] PyList_Reverse fails with C Extensions
Message-ID: <E14SM62-0000Aj-00@usw-sf-web3.sourceforge.net>

Bug #132008, was updated on 2001-Feb-12 08:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: whack
Assigned to : nobody
Summary: PyList_Reverse fails with C Extensions

Details: The C API function 'PyList_Reverse()' causes a 'Segmentation
Fault(core dump)' when used under:
Python 2.0 (#1, Oct 27 2000, 09:38:44) [C] on sunos5

A simple C function was written to accept a Python list as
input and return it in reverse using 'PyList_Reverse()'.
When compiled under Python1.5.2, this code works flawlessly.
I use the function under Python in this manner:
Python 1.5.2 (#2, Apr 17 1999, 11:16:17) [C] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import casette
>>> shape = casette.casette([1,2,3,4])
>>> shape
[4, 3, 2, 1]

However, when compiled under Python2.0, it returns the
following error:
Python 2.0 (#1, Oct 27 2000, 09:38:44) [C] on sunos5
Type "copyright", "credits" or "license" for more information.
>>> import casette
>>> shape = casette.casette([1,2,3,4])
Segmentation fault (core dumped)

and exits from Python altogether. 

I can provide the test program (with Makefile) if it 
would help track down the bug. Any indication of the
cause of this bug or a work around would be appreciated.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132008&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 16:51:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 08:51:35 -0800
Subject: [Python-bugs-list] [Bug #132010] urllib and httplib fails to open url
Message-ID: <E14SMCN-0000Dl-00@usw-sf-web3.sourceforge.net>

Bug #132010, was updated on 2001-Feb-12 08:51
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: apederse
Assigned to : nobody
Summary: urllib and httplib fails to open url

Details: urllib and httplib fails to open the URL:
"http://www.redherring.com/". By examining network traffic a request and
response from server is taking place but python simply hangs with an
"connection reset by peer" when it tries to open this particular URL.
Fredrik Lundh had a work-around to this problem while using httplib by
doing an explicit socket.close(), however I believe that more people should
look into the problem and hopefully a fix could be available for both
urllib and httplib. The problem has been reported to fail under both
version 1.5.2 and 2.0, however I have only tested it under ver.1.5.2

for more details do also take a look at:
http://x61.deja.com/%5BST_rn=ps%5D/viewthread.xp?AN=725477609&search=thread&svcclass=dnyr&ST=PS&CONTEXT=981992343.458686528&HIT_CONTEXT=981992343.458686528&HIT_NUM=0&recnum=%3c95th67$36j$1@nnrp1.deja.com%3e%231/1&group=comp.lang.python&frpage=viewthread.xp&back=clarinet


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132010&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 17:20:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 09:20:20 -0800
Subject: [Python-bugs-list] [Bug #131635] ConfigParser module regexp issue
Message-ID: <E14SMeC-0000Qz-00@usw-sf-web3.sourceforge.net>

Bug #131635, was updated on 2001-Feb-08 18:16
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 5
Submitted by: nobody
Assigned to : fdrake
Summary: ConfigParser module regexp issue

Details: In the ConfigParser module, a section header with a space
character is not allowed by the regexp search function.  This disallows
parsing of GNOME desktop application files
(/usr/share/gnome/apps/*/*.desktop on Red Hat 7.0).  Also, the option
regexp search errors on internationalized options such as the line:
Name[bg]=Vim

System: Red Hat 7.0
Python version: 1.5.2 (Red Hat packaged)


Follow-Ups:

Date: 2001-Feb-12 09:20
By: fdrake

Comment:
ConfigParser was already modified to allow spaces in section names since
the 1.5.2 release.  Added support for square brackets in
Lib/ConfigParser.py revision 1.30.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131635&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 17:39:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 09:39:13 -0800
Subject: [Python-bugs-list] [Bug #131304] a few misprints in 2.0 Python/C  API manual
Message-ID: <E14SMwT-0007O5-00@usw-sf-web2.sourceforge.net>

Bug #131304, was updated on 2001-Feb-06 10:33
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : fdrake
Summary: a few misprints in 2.0 Python/C  API manual

Details: In section 7.2.4, Tuple Objects, various
functions, such as PyTuple_Size, PyTuple_GetItem,
PyTuple_GetSlice are listed as taking a PyTupleObject *.
In tupleobject.h they are declared to take PyObject *.
This just causes some warnings I guess.

Also  I see that _PyTuple_Resize is listed as taking a PyTupleObject
*,while in tupleobject.h it is declared to take PyObject **.  I haven't
tried this function but
I suppose this is a more significant difference.

... Since I'm not an expert and just getting started writing an extension I
hope I'm not wasting your time with these.

cheers,
John
John R. Baxter
baxter@math.umn.edu

Follow-Ups:

Date: 2001-Feb-12 09:39
By: fdrake

Comment:
Not a waste of time; these were real bugs!

Fixed in Doc/api/api.tex revision 1.107.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131304&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 17:40:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 09:40:21 -0800
Subject: [Python-bugs-list] [Bug #131653] compile.py, mentioned in documentation, unaccessible
Message-ID: <E14SMxZ-0007Ow-00@usw-sf-web2.sourceforge.net>

Bug #131653, was updated on 2001-Feb-08 21:56
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : fdrake
Summary: compile.py, mentioned in documentation, unaccessible

Details: In "Extending and Embedding the Python Interpreter" section 3.1
(reference for Windows platform) refers to getting David Ascher's
"compile.py" from http://starship.python.net/crew/da/compile/

This link is dead.  I have tried to follow this up with David Ascher, but
haven't received a response.  So, after a couple of days waiting, I am
submitting it here as a bug in the documentation.

Follow-Ups:

Date: 2001-Feb-12 09:40
By: fdrake

Comment:
This is a duplicate of bug #121671.
-------------------------------------------------------

Date: 2001-Feb-09 16:00
By: tim_one

Comment:
Assigned to Fred.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131653&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 18:36:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 10:36:12 -0800
Subject: [Python-bugs-list] [Bug #132005] Making documentation requires Python 2.0+ (II)
Message-ID: <E14SNpc-0007o8-00@usw-sf-web2.sourceforge.net>

Bug #132005, was updated on 2001-Feb-12 08:28
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: jnelson
Assigned to : fdrake
Summary: Making documentation requires Python 2.0+ (II)

Details: Additional patching for #131725.
This should complete the patching necessary to make
it work under 1.5.2

Index: dist/src/Doc/tools/mkackshtml
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/tools/mkackshtml,v
retrieving revision 1.1
diff -u -r1.1 mkackshtml
--- dist/src/Doc/tools/mkackshtml       2000/10/05 05:15:29     1.1
+++ dist/src/Doc/tools/mkackshtml       2001/02/12 16:16:47
@@ -3,15 +3,15 @@
 
 import support
 import sys
+import string
 
-
 def collect(fp):
     names = []
     while 1:
         line = fp.readline()
         if not line:
             break
-        line = line.strip()
+        line = string.strip(line)
         if line:
             names.append(line)
         else:
@@ -26,22 +26,25 @@
     options.parse(sys.argv[1:])
     names = collect(sys.stdin)
     percol = (len(names) + options.columns - 1) / options.columns
-    colnums = [percol*i for i in range(options.columns)]
+    colnums = []
+    for i in range(options.columns):
+      colnums.append(percol*i)
+#    colnums = [percol*i for i in range(options.columns)]
     fp = options.get_output_file()
-    print >>fp, options.get_header().rstrip()
-    print >>fp, THANKS
-    print >>fp, '<table width="100%" align="center">'
+    fp.write(string.rstrip(options.get_header()) + "\n")
+    fp.write(THANKS + "\n")
+    fp.write('<table width="100%" align="center">\n')
     for i in range(percol):
-        print >>fp, "  <tr>"
+        fp.write("  <tr>\n")
         for j in colnums:
             try:
-                print >>fp, "    <td>%s</td>" % names[i + j]
+                fp.write("    <td>%s</td>\n" % names[i + j])
             except IndexError:
-                print >>fp, "    <td>&nbsp;</td>"
-        print >>fp, "  </tr>"
-    print >>fp, "</table>"
-    print >>fp, options.get_footer().rstrip()
-
+                fp.write("    <td>&nbsp;</td>\n")
+        fp.write("  </tr>\n")
+    fp.write("</table>\n")
+    fp.write(string.rstrip(options.get_footer()) + "\n")
+    fp.close()
 
 THANKS = '''\
 
Index: dist/src/Doc/tools/mkmodindex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/tools/mkmodindex,v
retrieving revision 1.10
diff -u -r1.10 mkmodindex
--- dist/src/Doc/tools/mkmodindex       2001/02/12 15:30:22     1.10
+++ dist/src/Doc/tools/mkmodindex       2001/02/12 16:16:47
@@ -52,8 +52,8 @@
     annotation = ""
 
     def __init__(self, link, str, seqno):
-        parts = str.split(None, 1)
-        if parts[0].endswith("</tt>"):
+        parts = string.split(str, None, 1)
+        if parts[0][-5] == "</tt>":
             self.modname = parts[0][:-5]
         else:
             self.modname = parts[0]


Follow-Ups:

Date: 2001-Feb-12 10:36
By: fdrake

Comment:
Assigned to me, mostly to get SF to mail me the patch.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132005&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 19:14:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 11:14:07 -0800
Subject: [Python-bugs-list] [Bug #132005] Making documentation requires Python 2.0+ (II)
Message-ID: <E14SOQJ-0000aS-00@usw-sf-web1.sourceforge.net>

Bug #132005, was updated on 2001-Feb-12 08:28
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: jnelson
Assigned to : fdrake
Summary: Making documentation requires Python 2.0+ (II)

Details: Additional patching for #131725.
This should complete the patching necessary to make
it work under 1.5.2

Index: dist/src/Doc/tools/mkackshtml
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/tools/mkackshtml,v
retrieving revision 1.1
diff -u -r1.1 mkackshtml
--- dist/src/Doc/tools/mkackshtml       2000/10/05 05:15:29     1.1
+++ dist/src/Doc/tools/mkackshtml       2001/02/12 16:16:47
@@ -3,15 +3,15 @@
 
 import support
 import sys
+import string
 
-
 def collect(fp):
     names = []
     while 1:
         line = fp.readline()
         if not line:
             break
-        line = line.strip()
+        line = string.strip(line)
         if line:
             names.append(line)
         else:
@@ -26,22 +26,25 @@
     options.parse(sys.argv[1:])
     names = collect(sys.stdin)
     percol = (len(names) + options.columns - 1) / options.columns
-    colnums = [percol*i for i in range(options.columns)]
+    colnums = []
+    for i in range(options.columns):
+      colnums.append(percol*i)
+#    colnums = [percol*i for i in range(options.columns)]
     fp = options.get_output_file()
-    print >>fp, options.get_header().rstrip()
-    print >>fp, THANKS
-    print >>fp, '<table width="100%" align="center">'
+    fp.write(string.rstrip(options.get_header()) + "\n")
+    fp.write(THANKS + "\n")
+    fp.write('<table width="100%" align="center">\n')
     for i in range(percol):
-        print >>fp, "  <tr>"
+        fp.write("  <tr>\n")
         for j in colnums:
             try:
-                print >>fp, "    <td>%s</td>" % names[i + j]
+                fp.write("    <td>%s</td>\n" % names[i + j])
             except IndexError:
-                print >>fp, "    <td>&nbsp;</td>"
-        print >>fp, "  </tr>"
-    print >>fp, "</table>"
-    print >>fp, options.get_footer().rstrip()
-
+                fp.write("    <td>&nbsp;</td>\n")
+        fp.write("  </tr>\n")
+    fp.write("</table>\n")
+    fp.write(string.rstrip(options.get_footer()) + "\n")
+    fp.close()
 
 THANKS = '''\
 
Index: dist/src/Doc/tools/mkmodindex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/tools/mkmodindex,v
retrieving revision 1.10
diff -u -r1.10 mkmodindex
--- dist/src/Doc/tools/mkmodindex       2001/02/12 15:30:22     1.10
+++ dist/src/Doc/tools/mkmodindex       2001/02/12 16:16:47
@@ -52,8 +52,8 @@
     annotation = ""
 
     def __init__(self, link, str, seqno):
-        parts = str.split(None, 1)
-        if parts[0].endswith("</tt>"):
+        parts = string.split(str, None, 1)
+        if parts[0][-5] == "</tt>":
             self.modname = parts[0][:-5]
         else:
             self.modname = parts[0]


Follow-Ups:

Date: 2001-Feb-12 11:14
By: fdrake

Comment:
Patches should really be submitted via the patch manager!

Checked in a slightly modified patch as Doc/tools/mkackshtml revision 1.2
and Doc/tools/mkmodindex revision 1.11.

Thanks!
-------------------------------------------------------

Date: 2001-Feb-12 10:36
By: fdrake

Comment:
Assigned to me, mostly to get SF to mail me the patch.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132005&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 20:21:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 12:21:43 -0800
Subject: [Python-bugs-list] [Bug #132008] PyList_Reverse fails with C Extensions
Message-ID: <E14SPTj-0001IB-00@usw-sf-web1.sourceforge.net>

Bug #132008, was updated on 2001-Feb-12 08:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: whack
Assigned to : tim_one
Summary: PyList_Reverse fails with C Extensions

Details: The C API function 'PyList_Reverse()' causes a 'Segmentation
Fault(core dump)' when used under:
Python 2.0 (#1, Oct 27 2000, 09:38:44) [C] on sunos5

A simple C function was written to accept a Python list as
input and return it in reverse using 'PyList_Reverse()'.
When compiled under Python1.5.2, this code works flawlessly.
I use the function under Python in this manner:
Python 1.5.2 (#2, Apr 17 1999, 11:16:17) [C] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import casette
>>> shape = casette.casette([1,2,3,4])
>>> shape
[4, 3, 2, 1]

However, when compiled under Python2.0, it returns the
following error:
Python 2.0 (#1, Oct 27 2000, 09:38:44) [C] on sunos5
Type "copyright", "credits" or "license" for more information.
>>> import casette
>>> shape = casette.casette([1,2,3,4])
Segmentation fault (core dumped)

and exits from Python altogether. 

I can provide the test program (with Makefile) if it 
would help track down the bug. Any indication of the
cause of this bug or a work around would be appreciated.


Follow-Ups:

Date: 2001-Feb-12 12:21
By: tim_one

Comment:
Raised priority, assigned to me.

Offhand, looks like one of those cases where the worker function
(listreverse) was changed to use PyArg_ParseTuple, but the API wrapper
function (PyList_Reverse) passes NULL for args instead of an empty tuple. 
Boom.  list.reverse() at Python level uses the worker function directly. so
only an extension module would bump into this (PyList_Reverse isn't used
anywhere within Python).

whack, this should get fixed for the 2.1b1 release.  In the meantime, try
invoking the reverse *method* on your list object.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132008&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 21:43:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 13:43:57 -0800
Subject: [Python-bugs-list] [Bug #132008] PyList_Reverse fails with C Extensions
Message-ID: <E14SQlJ-0002WA-00@usw-sf-web3.sourceforge.net>

Bug #132008, was updated on 2001-Feb-12 08:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: whack
Assigned to : gvanrossum
Summary: PyList_Reverse fails with C Extensions

Details: The C API function 'PyList_Reverse()' causes a 'Segmentation
Fault(core dump)' when used under:
Python 2.0 (#1, Oct 27 2000, 09:38:44) [C] on sunos5

A simple C function was written to accept a Python list as
input and return it in reverse using 'PyList_Reverse()'.
When compiled under Python1.5.2, this code works flawlessly.
I use the function under Python in this manner:
Python 1.5.2 (#2, Apr 17 1999, 11:16:17) [C] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import casette
>>> shape = casette.casette([1,2,3,4])
>>> shape
[4, 3, 2, 1]

However, when compiled under Python2.0, it returns the
following error:
Python 2.0 (#1, Oct 27 2000, 09:38:44) [C] on sunos5
Type "copyright", "credits" or "license" for more information.
>>> import casette
>>> shape = casette.casette([1,2,3,4])
Segmentation fault (core dumped)

and exits from Python altogether. 

I can provide the test program (with Makefile) if it 
would help track down the bug. Any indication of the
cause of this bug or a work around would be appreciated.


Follow-Ups:

Date: 2001-Feb-12 13:43
By: gvanrossum

Comment:
I'll take care of this.
-------------------------------------------------------

Date: 2001-Feb-12 12:21
By: tim_one

Comment:
Raised priority, assigned to me.

Offhand, looks like one of those cases where the worker function
(listreverse) was changed to use PyArg_ParseTuple, but the API wrapper
function (PyList_Reverse) passes NULL for args instead of an empty tuple. 
Boom.  list.reverse() at Python level uses the worker function directly. so
only an extension module would bump into this (PyList_Reverse isn't used
anywhere within Python).

whack, this should get fixed for the 2.1b1 release.  In the meantime, try
invoking the reverse *method* on your list object.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132008&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 22:15:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 14:15:14 -0800
Subject: [Python-bugs-list] [Bug #132008] PyList_Reverse fails with C Extensions
Message-ID: <E14SRFa-0001AU-00@usw-sf-web2.sourceforge.net>

Bug #132008, was updated on 2001-Feb-12 08:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: whack
Assigned to : gvanrossum
Summary: PyList_Reverse fails with C Extensions

Details: The C API function 'PyList_Reverse()' causes a 'Segmentation
Fault(core dump)' when used under:
Python 2.0 (#1, Oct 27 2000, 09:38:44) [C] on sunos5

A simple C function was written to accept a Python list as
input and return it in reverse using 'PyList_Reverse()'.
When compiled under Python1.5.2, this code works flawlessly.
I use the function under Python in this manner:
Python 1.5.2 (#2, Apr 17 1999, 11:16:17) [C] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import casette
>>> shape = casette.casette([1,2,3,4])
>>> shape
[4, 3, 2, 1]

However, when compiled under Python2.0, it returns the
following error:
Python 2.0 (#1, Oct 27 2000, 09:38:44) [C] on sunos5
Type "copyright", "credits" or "license" for more information.
>>> import casette
>>> shape = casette.casette([1,2,3,4])
Segmentation fault (core dumped)

and exits from Python altogether. 

I can provide the test program (with Makefile) if it 
would help track down the bug. Any indication of the
cause of this bug or a work around would be appreciated.


Follow-Ups:

Date: 2001-Feb-12 14:15
By: tim_one

Comment:
Related patches checked in:
_testcapimodule.c rev 1.2
    make sure PyList_Reverse doesn't blow up again
getargs.c rev 2.54
    assert args isn't NULL at the top of vgetargs1 instead of
    waiting for a NULL-pointer dereference at the end
-------------------------------------------------------

Date: 2001-Feb-12 13:43
By: gvanrossum

Comment:
I'll take care of this.
-------------------------------------------------------

Date: 2001-Feb-12 12:21
By: tim_one

Comment:
Raised priority, assigned to me.

Offhand, looks like one of those cases where the worker function
(listreverse) was changed to use PyArg_ParseTuple, but the API wrapper
function (PyList_Reverse) passes NULL for args instead of an empty tuple. 
Boom.  list.reverse() at Python level uses the worker function directly. so
only an extension module would bump into this (PyList_Reverse isn't used
anywhere within Python).

whack, this should get fixed for the 2.1b1 release.  In the meantime, try
invoking the reverse *method* on your list object.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132008&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 22:21:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 14:21:18 -0800
Subject: [Python-bugs-list] [Bug #132008] PyList_Reverse fails with C Extensions
Message-ID: <E14SRLS-0002oS-00@usw-sf-web3.sourceforge.net>

Bug #132008, was updated on 2001-Feb-12 08:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Closed
Resolution: None
Bug Group: None
Priority: 7
Submitted by: whack
Assigned to : gvanrossum
Summary: PyList_Reverse fails with C Extensions

Details: The C API function 'PyList_Reverse()' causes a 'Segmentation
Fault(core dump)' when used under:
Python 2.0 (#1, Oct 27 2000, 09:38:44) [C] on sunos5

A simple C function was written to accept a Python list as
input and return it in reverse using 'PyList_Reverse()'.
When compiled under Python1.5.2, this code works flawlessly.
I use the function under Python in this manner:
Python 1.5.2 (#2, Apr 17 1999, 11:16:17) [C] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import casette
>>> shape = casette.casette([1,2,3,4])
>>> shape
[4, 3, 2, 1]

However, when compiled under Python2.0, it returns the
following error:
Python 2.0 (#1, Oct 27 2000, 09:38:44) [C] on sunos5
Type "copyright", "credits" or "license" for more information.
>>> import casette
>>> shape = casette.casette([1,2,3,4])
Segmentation fault (core dumped)

and exits from Python altogether. 

I can provide the test program (with Makefile) if it 
would help track down the bug. Any indication of the
cause of this bug or a work around would be appreciated.


Follow-Ups:

Date: 2001-Feb-12 14:21
By: gvanrossum

Comment:
All taken care of.

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

Date: 2001-Feb-12 14:15
By: tim_one

Comment:
Related patches checked in:
_testcapimodule.c rev 1.2
    make sure PyList_Reverse doesn't blow up again
getargs.c rev 2.54
    assert args isn't NULL at the top of vgetargs1 instead of
    waiting for a NULL-pointer dereference at the end
-------------------------------------------------------

Date: 2001-Feb-12 13:43
By: gvanrossum

Comment:
I'll take care of this.
-------------------------------------------------------

Date: 2001-Feb-12 12:21
By: tim_one

Comment:
Raised priority, assigned to me.

Offhand, looks like one of those cases where the worker function
(listreverse) was changed to use PyArg_ParseTuple, but the API wrapper
function (PyList_Reverse) passes NULL for args instead of an empty tuple. 
Boom.  list.reverse() at Python level uses the worker function directly. so
only an extension module would bump into this (PyList_Reverse isn't used
anywhere within Python).

whack, this should get fixed for the 2.1b1 release.  In the meantime, try
invoking the reverse *method* on your list object.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132008&group_id=5470


From noreply@sourceforge.net  Mon Feb 12 22:25:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 14:25:11 -0800
Subject: [Python-bugs-list] [Bug #132008] PyList_Reverse fails with C Extensions
Message-ID: <E14SRPD-0001FO-00@usw-sf-web2.sourceforge.net>

Bug #132008, was updated on 2001-Feb-12 08:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Submitted by: whack
Assigned to : gvanrossum
Summary: PyList_Reverse fails with C Extensions

Details: The C API function 'PyList_Reverse()' causes a 'Segmentation
Fault(core dump)' when used under:
Python 2.0 (#1, Oct 27 2000, 09:38:44) [C] on sunos5

A simple C function was written to accept a Python list as
input and return it in reverse using 'PyList_Reverse()'.
When compiled under Python1.5.2, this code works flawlessly.
I use the function under Python in this manner:
Python 1.5.2 (#2, Apr 17 1999, 11:16:17) [C] on sunos5
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import casette
>>> shape = casette.casette([1,2,3,4])
>>> shape
[4, 3, 2, 1]

However, when compiled under Python2.0, it returns the
following error:
Python 2.0 (#1, Oct 27 2000, 09:38:44) [C] on sunos5
Type "copyright", "credits" or "license" for more information.
>>> import casette
>>> shape = casette.casette([1,2,3,4])
Segmentation fault (core dumped)

and exits from Python altogether. 

I can provide the test program (with Makefile) if it 
would help track down the bug. Any indication of the
cause of this bug or a work around would be appreciated.


Follow-Ups:

Date: 2001-Feb-12 14:25
By: tim_one

Comment:
Change Resolution to Fixed.  The fix is in listobject.c rev 2.92.
-------------------------------------------------------

Date: 2001-Feb-12 14:21
By: gvanrossum

Comment:
All taken care of.

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

Date: 2001-Feb-12 14:15
By: tim_one

Comment:
Related patches checked in:
_testcapimodule.c rev 1.2
    make sure PyList_Reverse doesn't blow up again
getargs.c rev 2.54
    assert args isn't NULL at the top of vgetargs1 instead of
    waiting for a NULL-pointer dereference at the end
-------------------------------------------------------

Date: 2001-Feb-12 13:43
By: gvanrossum

Comment:
I'll take care of this.
-------------------------------------------------------

Date: 2001-Feb-12 12:21
By: tim_one

Comment:
Raised priority, assigned to me.

Offhand, looks like one of those cases where the worker function
(listreverse) was changed to use PyArg_ParseTuple, but the API wrapper
function (PyList_Reverse) passes NULL for args instead of an empty tuple. 
Boom.  list.reverse() at Python level uses the worker function directly. so
only an extension module would bump into this (PyList_Reverse isn't used
anywhere within Python).

whack, this should get fixed for the 2.1b1 release.  In the meantime, try
invoking the reverse *method* on your list object.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132008&group_id=5470


From noreply@sourceforge.net  Tue Feb 13 02:29:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 18:29:19 -0800
Subject: [Python-bugs-list] [Bug #132124] [PATCH] simple fix, cgi.py uses /usr/local/bin/python ?
Message-ID: <E14SVDT-00035g-00@usw-sf-web2.sourceforge.net>

Bug #132124, was updated on 2001-Feb-12 18:29
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: gbsadler
Assigned to : nobody
Summary: [PATCH] simple fix, cgi.py uses /usr/local/bin/python ?

Details: Index: Lib/cgi.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/cgi.py,v
retrieving revision 1.60
diff -p -u -r1.60 cgi.py
--- Lib/cgi.py  2001/02/09 09:59:10     1.60
+++ Lib/cgi.py  2001/02/13 02:23:39
@@ -1,4 +1,4 @@
-#! /usr/local/bin/python
+#! /usr/bin/env python

 """Support module for CGI (Common Gateway Interface) scripts.

See no reason for /usr/local/bin...

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132124&group_id=5470


From noreply@sourceforge.net  Tue Feb 13 05:19:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 12 Feb 2001 21:19:53 -0800
Subject: [Python-bugs-list] [Bug #132136] traceback module gets out of sync source lines
Message-ID: <E14SXsX-0005g1-00@usw-sf-web3.sourceforge.net>

Bug #132136, was updated on 2001-Feb-12 21:19
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: traceback module gets out of sync source lines

Details: the line numbers printed by the traceback module
can get out of sync when modules are reload()ed.
this is confusing.

it seems to me the simplest solution is to disable caching of the source
files altogether, since printing tracebacks is not often a very performance
critical task. 

  -- erno@iki.fi


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132136&group_id=5470


From noreply@sourceforge.net  Tue Feb 13 10:12:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Feb 2001 02:12:46 -0800
Subject: [Python-bugs-list] [Bug #131996] wrong argument list for "def _cmp(...)" in filecmp.py
Message-ID: <E14ScRy-0000hS-00@usw-sf-web1.sourceforge.net>

Bug #131996, was updated on 2001-Feb-12 05:21
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : moshez
Summary: wrong argument list for "def _cmp(...)" in filecmp.py

Details: to whom it may concern,

in the file filecmp.py please check the method _cmp(...) - I try to use
"dircmp(dir_a, dir_b) and get the following messages:

Traceback (most recent call last):
  File "\users\lib\filecmp.py", line 328, in ?
    demo()
  File "\users\lib\filecmp.py", line 323, in demo
    dd.report_full_closure()
  File "\users\lib\filecmp.py", line 264, in report_full_closure
    self.report()
  File "\users\lib\filecmp.py", line 241, in report
    if self.same_files:
  File "\users\lib\filecmp.py", line 147, in __getattr__
    self.phase3()
  File "\users\lib\filecmp.py", line 214, in phase3
    xx = cmpfiles(self.left, self.right, self.common_files)
  File "\users\lib\filecmp.py", line 288, in cmpfiles
    res[_cmp(ax, bx, shallow, use_statcache)].append(x)
TypeError: too many arguments; expected 2, got 4

Please correct the method _cmp(...)

thanks


Follow-Ups:

Date: 2001-Feb-13 02:12
By: tim_one

Comment:
This was fixed late last year by Moshe, in filecmp.py rev 1.7.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131996&group_id=5470


From noreply@sourceforge.net  Tue Feb 13 10:15:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Feb 2001 02:15:04 -0800
Subject: [Python-bugs-list] [Bug #132010] urllib and httplib fails to open url
Message-ID: <E14ScUC-0000jA-00@usw-sf-web1.sourceforge.net>

Bug #132010, was updated on 2001-Feb-12 08:51
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: apederse
Assigned to : effbot
Summary: urllib and httplib fails to open url

Details: urllib and httplib fails to open the URL:
"http://www.redherring.com/". By examining network traffic a request and
response from server is taking place but python simply hangs with an
"connection reset by peer" when it tries to open this particular URL.
Fredrik Lundh had a work-around to this problem while using httplib by
doing an explicit socket.close(), however I believe that more people should
look into the problem and hopefully a fix could be available for both
urllib and httplib. The problem has been reported to fail under both
version 1.5.2 and 2.0, however I have only tested it under ver.1.5.2

for more details do also take a look at:
http://x61.deja.com/%5BST_rn=ps%5D/viewthread.xp?AN=725477609&search=thread&svcclass=dnyr&ST=PS&CONTEXT=981992343.458686528&HIT_CONTEXT=981992343.458686528&HIT_NUM=0&recnum=%3c95th67$36j$1@nnrp1.deja.com%3e%231/1&group=comp.lang.python&frpage=viewthread.xp&back=clarinet


Follow-Ups:

Date: 2001-Feb-13 02:15
By: tim_one

Comment:
Assigned to /F since he's already looked at this.  So what's up with
redherring.com?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132010&group_id=5470


From noreply@sourceforge.net  Tue Feb 13 10:22:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Feb 2001 02:22:42 -0800
Subject: [Python-bugs-list] [Bug #132124] [PATCH] simple fix, cgi.py uses /usr/local/bin/python ?
Message-ID: <E14Scba-0007if-00@usw-sf-web3.sourceforge.net>

Bug #132124, was updated on 2001-Feb-12 18:29
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: None
Resolution: None
Bug Group: None
Priority: 5
Submitted by: gbsadler
Assigned to : gvanrossum
Summary: [PATCH] simple fix, cgi.py uses /usr/local/bin/python ?

Details: Index: Lib/cgi.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/cgi.py,v
retrieving revision 1.60
diff -p -u -r1.60 cgi.py
--- Lib/cgi.py  2001/02/09 09:59:10     1.60
+++ Lib/cgi.py  2001/02/13 02:23:39
@@ -1,4 +1,4 @@
-#! /usr/local/bin/python
+#! /usr/bin/env python

 """Support module for CGI (Common Gateway Interface) scripts.

See no reason for /usr/local/bin...

Follow-Ups:

Date: 2001-Feb-13 02:22
By: tim_one

Comment:
Assigned to Guido.  My understanding is that /usr/bin/env often isn't
available in CGI environments, which is why cgi.py is unique in using
/usr/local/bin/python.  But what do I know ... if that is the case, how
about adding a comment to cgi.py explaining it?  IIRC, this isn't the first
time we got a fix for this "bug".
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132124&group_id=5470


From noreply@sourceforge.net  Tue Feb 13 10:48:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Feb 2001 02:48:52 -0800
Subject: [Python-bugs-list] [Bug #132136] traceback module gets out of sync source lines
Message-ID: <E14Sd0u-0006M1-00@usw-sf-web2.sourceforge.net>

Bug #132136, was updated on 2001-Feb-12 21:19
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : gvanrossum
Summary: traceback module gets out of sync source lines

Details: the line numbers printed by the traceback module
can get out of sync when modules are reload()ed.
this is confusing.

it seems to me the simplest solution is to disable caching of the source
files altogether, since printing tracebacks is not often a very performance
critical task. 

  -- erno@iki.fi


Follow-Ups:

Date: 2001-Feb-13 02:48
By: tim_one

Comment:
Assigned to Guido, cuz this stuff is tricky but more importantly is his
<wink>.  I note that IDLE's PyShell.py does some very evil stuff to
overwrite linecache.checkcache -- but AFAICT linecache.checkcache is never
called by anything in the entire distribution.  That would go a long way
toward explaining why the cache gets stale ... and linecache.py clearly
isn't threadsafe either, but that's a bug for another day ...
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132136&group_id=5470


From noreply@sourceforge.net  Tue Feb 13 13:14:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Feb 2001 05:14:36 -0800
Subject: [Python-bugs-list] [Bug #132124] [PATCH] simple fix, cgi.py uses /usr/local/bin/python ?
Message-ID: <E14SfHw-0007NN-00@usw-sf-web2.sourceforge.net>

Bug #132124, was updated on 2001-Feb-12 18:29
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 5
Submitted by: gbsadler
Assigned to : gvanrossum
Summary: [PATCH] simple fix, cgi.py uses /usr/local/bin/python ?

Details: Index: Lib/cgi.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/cgi.py,v
retrieving revision 1.60
diff -p -u -r1.60 cgi.py
--- Lib/cgi.py  2001/02/09 09:59:10     1.60
+++ Lib/cgi.py  2001/02/13 02:23:39
@@ -1,4 +1,4 @@
-#! /usr/local/bin/python
+#! /usr/bin/env python

 """Support module for CGI (Common Gateway Interface) scripts.

See no reason for /usr/local/bin...

Follow-Ups:

Date: 2001-Feb-13 05:14
By: gvanrossum

Comment:
Good idea.  Comment added.  Here it is:

# NOTE: the above "/usr/local/bin/python" is NOT a mistake.  It is
# intentionally NOT "/usr/bin/env python".  On many systems
# (e.g. Solaris), /usr/local/bin is not in $PATH as passed to CGI
# scripts, and /usr/local/bin is the default directory where Python is
# installed, so /usr/bin/env would be unable to find python.  Granted,
# binary installations by Linux vendors often install Python in
# /usr/bin.  So let those vendors patch cgi.py to match their choice
# of installation.

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

Date: 2001-Feb-13 02:22
By: tim_one

Comment:
Assigned to Guido.  My understanding is that /usr/bin/env often isn't
available in CGI environments, which is why cgi.py is unique in using
/usr/local/bin/python.  But what do I know ... if that is the case, how
about adding a comment to cgi.py explaining it?  IIRC, this isn't the first
time we got a fix for this "bug".
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132124&group_id=5470


From noreply@sourceforge.net  Tue Feb 13 13:49:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Feb 2001 05:49:38 -0800
Subject: [Python-bugs-list] [Bug #132136] traceback module gets out of sync source lines
Message-ID: <E14Sfpq-0007d0-00@usw-sf-web2.sourceforge.net>

Bug #132136, was updated on 2001-Feb-12 21:19
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : gvanrossum
Summary: traceback module gets out of sync source lines

Details: the line numbers printed by the traceback module
can get out of sync when modules are reload()ed.
this is confusing.

it seems to me the simplest solution is to disable caching of the source
files altogether, since printing tracebacks is not often a very performance
critical task. 

  -- erno@iki.fi


Follow-Ups:

Date: 2001-Feb-13 05:49
By: gvanrossum

Comment:
I suggest that you call linecache.clearcache() when you use reload().

No time to think about this more right now; I created the cache because I
perceived an unpleasant slowness. Often the same file shows up multiple
times in the same traceback.  Perhaps the traceback module could clear the
cache before it starts?

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

Date: 2001-Feb-13 02:48
By: tim_one

Comment:
Assigned to Guido, cuz this stuff is tricky but more importantly is his
<wink>.  I note that IDLE's PyShell.py does some very evil stuff to
overwrite linecache.checkcache -- but AFAICT linecache.checkcache is never
called by anything in the entire distribution.  That would go a long way
toward explaining why the cache gets stale ... and linecache.py clearly
isn't threadsafe either, but that's a bug for another day ...
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132136&group_id=5470


From noreply@sourceforge.net  Tue Feb 13 17:03:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Feb 2001 09:03:15 -0800
Subject: [Python-bugs-list] [Bug #132195] python 2.0 not compile with g++
Message-ID: <E14SirD-0002Jq-00@usw-sf-web3.sourceforge.net>

Bug #132195, was updated on 2001-Feb-13 09:03
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: python 2.0 not compile with g++

Details: 
  I downloaded python 2.0 on

%uname -a
Linux (etc) 2.0.36 #1 Tue Oct 13 22:17:11 EDT 1998 i686 unknown
% g++ -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.90.29/specs
gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)

and it did not compile. The words "new" and "class"
were used as variables (for instance) in the 
Parser directory.

Mark

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132195&group_id=5470


From noreply@sourceforge.net  Tue Feb 13 17:32:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Feb 2001 09:32:07 -0800
Subject: [Python-bugs-list] [Bug #132195] python 2.0 not compile with g++
Message-ID: <E14SjJ9-0002XR-00@usw-sf-web3.sourceforge.net>

Bug #132195, was updated on 2001-Feb-13 09:03
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: python 2.0 not compile with g++

Details: 
  I downloaded python 2.0 on

%uname -a
Linux (etc) 2.0.36 #1 Tue Oct 13 22:17:11 EDT 1998 i686 unknown
% g++ -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.90.29/specs
gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)

and it did not compile. The words "new" and "class"
were used as variables (for instance) in the 
Parser directory.

Mark

Follow-Ups:

Date: 2001-Feb-13 09:32
By: gvanrossum

Comment:
Well what do you expect?  It's a C program, not a C++ program.

Try using gcc.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132195&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 00:56:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Feb 2001 16:56:05 -0800
Subject: [Python-bugs-list] [Bug #132276] make install not working
Message-ID: <E14SqEn-0001Ev-00@usw-sf-web1.sourceforge.net>

Bug #132276, was updated on 2001-Feb-13 16:56
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: make install not working

Details: can't figure out why im gittin this problem


# make install
./install-sh -c python /usr/local/bin/python2.1
if test -f libpython2.1.so; then \
        ./install-sh -c -m 644 libpython2.1.so /usr/local/lib; \
else    true; \
fi
if test -f ""; then \
        ./install-sh -c -m 644  /usr/local/bin; \
else    true; \
fi
Creating directory /usr/local/lib/python2.1
cp: illegal option -- d
cp: Insufficient arguments (1)
Usage: cp [-f] [-i] [-p] f1 f2
       cp [-f] [-i] [-p] f1 ... fn d1
       cp -r|R [-f] [-i] [-p] d1 ... dn-1 dn
*** Error code 2
make: Fatal error: Command failed for target `libinstall'


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132276&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 01:22:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 13 Feb 2001 17:22:13 -0800
Subject: [Python-bugs-list] [Bug #132288] Config Parser .ini "Gotcha"
Message-ID: <E14Sqe5-00068X-00@usw-sf-web3.sourceforge.net>

Bug #132288, was updated on 2001-Feb-13 17:22
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: Config Parser .ini "Gotcha"

Details: Problem:  
I'm working on a windows-specific app, which makes heavy use of .ini files.
 A lot of our section names are in the form [WorkClass\WorkType]. 
ConfigParser currently chokes on that style section name.

I couldn't tell whether this is legal according to the RFC on which this is
based.  But it's required for what we're doing.

Fix:
My version of ConfigParser.py has this statement beginning at 381.  The
change is so small that it doesn't seem worth actually doing a full-blown
diff.

Anyway.  Change:
SECTCRE = re.compile(
    r'\['                                 # [
    r'(?P<header>[-\w_.*,(){} ]+)'        # comment here
    r'\]'                                 # ]
        )

to:
SECTCRE = re.compile(
    r'\['                                 # [
    r'(?P<header>[-\w_.*,(){} \\]+)'      # same comment
    r'\]'                                 # ]
        )

And the problem goes away.

My apologies for not logging in.  I'm submitting this from work, and they
won't allow us to upgrade IE (which Source Forge says it requires).

Thanks!



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132288&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 08:45:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 00:45:30 -0800
Subject: [Python-bugs-list] [Bug #132313] error message confusing for assignment in lambda
Message-ID: <E14SxZ4-0007Z3-00@usw-sf-web2.sourceforge.net>

Bug #132313, was updated on 2001-Feb-14 00:45
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: error message confusing for assignment in lambda

Details: Python 2.1a1 (#4, Feb 11 2001, 16:05:58) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> map(lambda foo: foo[0] = 4, [[1, 2]*3])
SyntaxError: keyword can't be an expression


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132313&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 14:36:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 06:36:14 -0800
Subject: [Python-bugs-list] [Bug #132276] make install not working
Message-ID: <E14T32U-00030C-00@usw-sf-web3.sourceforge.net>

Bug #132276, was updated on 2001-Feb-13 16:56
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: make install not working

Details: can't figure out why im gittin this problem


# make install
./install-sh -c python /usr/local/bin/python2.1
if test -f libpython2.1.so; then \
        ./install-sh -c -m 644 libpython2.1.so /usr/local/lib; \
else    true; \
fi
if test -f ""; then \
        ./install-sh -c -m 644  /usr/local/bin; \
else    true; \
fi
Creating directory /usr/local/lib/python2.1
cp: illegal option -- d
cp: Insufficient arguments (1)
Usage: cp [-f] [-i] [-p] f1 f2
       cp [-f] [-i] [-p] f1 ... fn d1
       cp -r|R [-f] [-i] [-p] d1 ... dn-1 dn
*** Error code 2
make: Fatal error: Command failed for target `libinstall'


Follow-Ups:

Date: 2001-Feb-14 06:36
By: gvanrossum

Comment:
What platform?

To further debug this, please insert "set -x" in the install-sh script
(after the first comment block) so you can see what it's doing.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132276&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 14:37:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 06:37:36 -0800
Subject: [Python-bugs-list] [Bug #132288] Config Parser .ini "Gotcha"
Message-ID: <E14T33o-0001V5-00@usw-sf-web2.sourceforge.net>

Bug #132288, was updated on 2001-Feb-13 17:22
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Submitted by: nobody
Assigned to : fdrake
Summary: Config Parser .ini "Gotcha"

Details: Problem:  
I'm working on a windows-specific app, which makes heavy use of .ini files.
 A lot of our section names are in the form [WorkClass\WorkType]. 
ConfigParser currently chokes on that style section name.

I couldn't tell whether this is legal according to the RFC on which this is
based.  But it's required for what we're doing.

Fix:
My version of ConfigParser.py has this statement beginning at 381.  The
change is so small that it doesn't seem worth actually doing a full-blown
diff.

Anyway.  Change:
SECTCRE = re.compile(
    r'\['                                 # [
    r'(?P<header>[-\w_.*,(){} ]+)'        # comment here
    r'\]'                                 # ]
        )

to:
SECTCRE = re.compile(
    r'\['                                 # [
    r'(?P<header>[-\w_.*,(){} \\]+)'      # same comment
    r'\]'                                 # ]
        )

And the problem goes away.

My apologies for not logging in.  I'm submitting this from work, and they
won't allow us to upgrade IE (which Source Forge says it requires).

Thanks!



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132288&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 14:42:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 06:42:42 -0800
Subject: [Python-bugs-list] [Bug #132313] error message confusing for assignment in lambda
Message-ID: <E14T38k-00033D-00@usw-sf-web3.sourceforge.net>

Bug #132313, was updated on 2001-Feb-14 00:45
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : tim_one
Summary: error message confusing for assignment in lambda

Details: Python 2.1a1 (#4, Feb 11 2001, 16:05:58) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> map(lambda foo: foo[0] = 4, [[1, 2]*3])
SyntaxError: keyword can't be an expression


Follow-Ups:

Date: 2001-Feb-14 06:42
By: gvanrossum

Comment:
Assigning to Tim Peters. My own inclination is to close this with a "Won't
Fix", because it's nearly impossible to get the parser to spit out a better
error message without completely reimplementing the parser using a
different approach. But Tim may want this to nag us more...

Background: while we would like the grammar for function arguments to be
[NAME '='] expression, our parser generator doesn't support that, and
unfortunately it has to have the form "expression ['=' expression]". Then
the code generator back-end does an additional check to make sure that if
the second expression is given (meaning this is a keyword argument), the
first expression is of the form NAME.  That's the error you're getting
here, because "lambda foo: foo[0]" happens to be a valid match for the
first expression.  I don't see an easy way to improve the error message.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132313&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 15:37:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 07:37:16 -0800
Subject: [Python-bugs-list] [Bug #132288] Config Parser .ini "Gotcha"
Message-ID: <E14T3zY-0001xa-00@usw-sf-web2.sourceforge.net>

Bug #132288, was updated on 2001-Feb-13 17:22
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 5
Submitted by: nobody
Assigned to : fdrake
Summary: Config Parser .ini "Gotcha"

Details: Problem:  
I'm working on a windows-specific app, which makes heavy use of .ini files.
 A lot of our section names are in the form [WorkClass\WorkType]. 
ConfigParser currently chokes on that style section name.

I couldn't tell whether this is legal according to the RFC on which this is
based.  But it's required for what we're doing.

Fix:
My version of ConfigParser.py has this statement beginning at 381.  The
change is so small that it doesn't seem worth actually doing a full-blown
diff.

Anyway.  Change:
SECTCRE = re.compile(
    r'\['                                 # [
    r'(?P<header>[-\w_.*,(){} ]+)'        # comment here
    r'\]'                                 # ]
        )

to:
SECTCRE = re.compile(
    r'\['                                 # [
    r'(?P<header>[-\w_.*,(){} \\]+)'      # same comment
    r'\]'                                 # ]
        )

And the problem goes away.

My apologies for not logging in.  I'm submitting this from work, and they
won't allow us to upgrade IE (which Source Forge says it requires).

Thanks!



Follow-Ups:

Date: 2001-Feb-14 07:37
By: fdrake

Comment:
Fixed in a fairly permissive way in Lib/ConfigParser.py revision 1.31, in
the hope that this problem will not re-surface with some other character in
the next release of Python.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132288&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 17:21:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 09:21:30 -0800
Subject: [Python-bugs-list] [Bug #131235] mpzmodule wont compile with msvc
Message-ID: <E14T5cQ-00020i-00@usw-sf-web1.sourceforge.net>

Bug #131235, was updated on 2001-Feb-06 02:10
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Fixed
Bug Group: Not a Bug
Priority: 5
Submitted by: mpmak
Assigned to : akuchling
Summary: mpzmodule wont compile with msvc

Details: 
Non const initializer in mpzmodule, around line 1587:
is:
PyObject_HEAD_INIT(&PyType_Type)
sholud be:
PyObject_HEAD_INIT(NULL)

and in module initialization:
MPZtype.ob_type = &PyType_Type;


Follow-Ups:

Date: 2001-Feb-08 09:22
By: akuchling

Comment:
This should already be fixed in CVS (someone else reported it for Cygwin). 
Can you grab a copy of the CVS tree and check that it's now OK?

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131235&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 17:22:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 09:22:30 -0800
Subject: [Python-bugs-list] [Bug #129788] cgi module. FieldStorage class returns keys blank fields.
Message-ID: <E14T5dO-00021K-00@usw-sf-web1.sourceforge.net>

Bug #129788, was updated on 2001-Jan-23 01:28
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Invalid
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : akuchling
Summary: cgi module. FieldStorage class returns keys blank fields.

Details: In module cgi.py

The FieldStorage class returns keys for blank values even though the
keep_blank_values property is set to 0

The problem lies in the parse_qsl method.
The second last line of the function
  r.append((name, value))
should read
  if (len(value) or keep_blank_values):
      r.append((name, value))  

I hope this can be corrected.

Thanks

Follow-Ups:

Date: 2001-Jan-28 18:59
By: nobody

Comment:
I don't see why this is necessary.  The r.append()
call is inside an if block whose condition is
'if len(nv[1]) or keep_blank_values'.  nv[1] then has + replaced with space
characters and is run through
urllib.unquote().  I'm unable to see how a non-empty string could result in
an empty string after urllib.unquote, and in fact
cgi.parse_qsl('abc=&foo=bar') returns [('foo', 'bar')].  Can you provide a
test case?

If a test case demonstrating the problem doesn't appear, this bug should be
marked as 'Not a bug' and cgi.py left alone.
-------------------------------------------------------

Date: 2001-Jan-26 07:29
By: fdrake

Comment:
Assigned to Andrew since he knows more about CGI stuff than I ever expect
to.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129788&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 17:27:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 09:27:27 -0800
Subject: [Python-bugs-list] [Bug #128251] Windows mmap docs need cleaning
Message-ID: <E14T5iB-00023v-00@usw-sf-web1.sourceforge.net>

Bug #128251, was updated on 2001-Jan-09 21:14
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Submitted by: tim_one
Assigned to : akuchling
Summary: Windows mmap docs need cleaning

Details: WRT the docs for the Windows flavor of mmap.mmap():

1) Doc needed:  The file *must* be opened for update (r+, w+, rb+ or wb+). 
That's because CreateFileMapping is called with PAGE_READWRITE, and that
won't let you increase permissions over the original open mode.  Violating
this yields baffling "The parameter is wrong" Windows errors from
mmap.mmap().

2) Doc needed:  Passing a size of 0 makes the maximum size of the mapping
the actual current size of the file.  Don't know whether that's also true
on Unices (ask AMK?); on Windows it's intentional; and it's handy to know
so it's worth documenting.

3) Doc bug:  The docs read as if omitting the optional tagname is different
than supplying a tagname of None.  I don't believe that's true; needs mild
rewording.

Fred and AMK and c.l.py got a longer version of this msg.  I think the
example of using mmap with re would be worth including too (but it would be
nice to have an example that isn't Windows-specific!  someone should try
that on Linux too, and fiddle as needed).


Follow-Ups:

Date: 2001-Jan-16 13:18
By: akuchling

Comment:
As far as I can tell, length==0 is an error on Unix.  It certainly
doesn't seem to mean anything special on Unix.

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

Date: 2001-Jan-11 14:51
By: fdrake

Comment:
I've updated the documentation according to Tim's comments in
Doc/lib/libmmap.tex revision 1.4.

Andrew: do you know anything about passing a length of zero on Unix?  I
wasn't able to find anything in the mmap() man page, and don't have ready
access to any other reference material at this time.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=128251&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 17:29:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 09:29:10 -0800
Subject: [Python-bugs-list] [Bug #115221] test_poll hangs on Debian Linux 2.2
Message-ID: <E14T5jq-0004Ib-00@usw-sf-web3.sourceforge.net>

Bug #115221, was updated on 2000-Sep-24 07:38
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 4
Submitted by: larsga
Assigned to : akuchling
Summary: test_poll hangs on Debian Linux 2.2

Details: When run from the command-line test_poll.py prints
"This is a test." 12 times and then hangs, without ever printing "Poll test
1 complete".

All other tests seem to work just fine.

Follow-Ups:

Date: 2000-Oct-13 13:18
By: larsga

Comment:
I just tried it now, and it did not fix the problem on my
Debian 2.2 system. It still hangs.
-------------------------------------------------------

Date: 2000-Oct-12 09:21
By: akuchling

Comment:
If the suggested patch actually fixes the test suite, I'd approve adding
it.  Have any of the original respondents tried the patch?
-------------------------------------------------------

Date: 2000-Oct-12 08:43
By: jhylton

Comment:
Does anyone care about this bug report anymore?  Since there has been no
response, I'm lowering the priority...
-------------------------------------------------------

Date: 2000-Oct-11 16:44
By: jhylton

Comment:
Would this patch fix the most recently reported problem?

Index: Lib/test/test_poll.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_poll.py,v
retrieving revision 1.3
diff -c -r1.3 test_poll.py
*** Lib/test/test_poll.py       2000/08/29 16:53:34     1.3
--- Lib/test/test_poll.py       2000/10/11 23:44:31
***************
*** 74,81 ****
          pass
      p = select.poll()
      p.register(FD)
!     r = p.poll()
!     assert r[0] == (FD, select.POLLNVAL)
  
      f = open(TESTFN, 'w')
      fd = f.fileno()
--- 74,87 ----
          pass
      p = select.poll()
      p.register(FD)
!     try:
!         r = p.poll()
!     except select.error, msg:
!         # old versions of Linux seem to raise an exception instead of
!         # returning POLLNVAL 
!         pass
!     else:
!         assert r[0] == (FD, select.POLLNVAL)
  
      f = open(TESTFN, 'w')
      fd = f.fileno()

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

Date: 2000-Oct-07 08:43
By: twouters

Comment:
When running test_poll on the current CVS tree on RedHat 5.2 with a 2.0.36
kernel, I also get a test_poll error, though not the same one:

 This is a test.
 This is a test.
[...]
test test_poll crashed -- select.error: (9, 'Bad file descriptor')
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 235, in runtest
    __import__(test, globals(), locals(), [])
  File "./Lib/test/test_poll.py", line 171, in ?
    test_poll1()
  File "./Lib/test/test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "./Lib/test/test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
error: (9, 'Bad file descriptor')
1 test failed: test_poll

RedHat 5.2 with a 2.2 kernel works fine. Let me know if you want me to
submit a separate bugreport for the rh52-kernel2.0-poll error.

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

Date: 2000-Oct-05 08:48
By: akuchling

Comment:
Interesting; Neil has libc6-2.1.3-13, while Lars has 2.1.3-10.  Presumably
that last tag is a release level?

On the other hand, Neil is running a 2.2 Linux while Lars is running
2.0.36, and Neil also reported problems with
poll on a 2.0 machine.  So the finger of suspicion is pointing at the
kernel...
-------------------------------------------------------

Date: 2000-Oct-05 08:43
By: larsga

Comment:
I did a "cvs update", recompiled and ran the regtest again. Problem still
persists.

Traceback is
Traceback (most recent call last):
  File "test_poll.py", line 171, in ?
    test_poll1()
  File "test_poll.py", line 65, in test_poll1
    poll_unit_tests()
  File "test_poll.py", line 77, in poll_unit_tests
    r = p.poll()
KeyboardInterrupt

[larsga@pc-larsga test]$ uname -a
Linux pc-larsga 2.0.36 #2 Sun Jan 17 19:38:45 EST 1999 i686 unknown
[larsga@pc-larsga test]$ dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libc6          2.1.3-10       GNU C Library: Shared libraries and
Timezone

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

Date: 2000-Oct-05 07:52
By: akuchling

Comment:
I don't have a Debian system to reproduce this on.

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

Date: 2000-Oct-05 07:17
By: jhylton

Comment:
Andrew -- Is this still a problem for you?  
-------------------------------------------------------

Date: 2000-Sep-27 10:58
By: nascheme

Comment:
I can't reproduce this on my Debian 2.2 system running Linux
 2.2.16.  Can you give the output from "uname -a" and "dpkg 
-l libc6"?  I am using libc6 2.1.3-13.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=115221&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 17:30:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 09:30:15 -0800
Subject: [Python-bugs-list] [Bug #130165] Python 2.1a1 Makefile changed OPT value not used in module c
Message-ID: <E14T5kt-0004JC-00@usw-sf-web3.sourceforge.net>

Bug #130165, was updated on 2001-Jan-26 06:46
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : akuchling
Summary: Python 2.1a1 Makefile changed OPT value not used in module c

Details: When the top level "Makefile" value used for the variable "OPT" is
changed
after executing "configure", that new value is used to compile "python",
but is *not* used during the compilation of the modules.


Follow-Ups:

Date: 2001-Feb-14 09:30
By: akuchling

Comment:
No comment from original submitter -- assuming this bug 
is obsolete.
-------------------------------------------------------

Date: 2001-Feb-07 14:37
By: akuchling

Comment:
Yes, but in 2.1alpha2 nothing should be doing 'cd Modules' at all, which is
why I'd like to know if it happens with either alpha2 or the current CVS
tree.

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

Date: 2001-Jan-30 00:47
By: nobody

Comment:
Updated more details by original submitter:

The problem appears shortly after a "cd Modules" but shows up only
during compilation of the ".so" extension modules.  The first module
compilation in the original 2.1a1 version to show the failure to use the
changed value of "OPT" follows the line:

	"building 'regex' extension"

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

Date: 2001-Jan-28 19:19
By: nobody

Comment:
I can't replicate this; when I edit the Makefile, the new OPT setting
is picked up by the setup script.  Does it still happen with the current
CVS version?
-------------------------------------------------------

Date: 2001-Jan-26 07:45
By: nascheme

Comment:
Hmm, perhaps the makefile could pass OPT to the distutils
setup.py script.  Andrew knows better than I how to solve
this.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130165&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 17:40:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 09:40:31 -0800
Subject: [Python-bugs-list] [Bug #131398] installation of Numeric for Python 2.0. is impossible
Message-ID: <E14T5up-0004NA-00@usw-sf-web3.sourceforge.net>

Bug #131398, was updated on 2001-Feb-07 05:28
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Closed
Resolution: Invalid
Bug Group: Platform-specific
Priority: 5
Submitted by: nobody
Assigned to : akuchling
Summary: installation of Numeric for Python 2.0. is impossible

Details: Hello, everyone.

I have troubles with installing Numeric for Python 2.0.
After I download file Numeric-17.0.tar to directory Python20 and decompress
it there,
I run:

D:\Python20\Numeric-17.3.0>python setup.py install
running install
running build
running build_py
not copying Lib\ArrayPrinter.py (output up-to-date)
not copying Lib\Numeric.py (output up-to-date)
not copying Lib\numeric_version.py (output up-to-date)
not copying Lib\Precision.py (output up-to-date)
not copying Lib\UserArray.py (output up-to-date)
running build_ext
skipping '_numpy' extension (up-to-date)
skipping 'multiarray' extension (up-to-date)
building 'umath' extension
skipping Src/umathmodule.c
(build\temp.win32-2.0\Release\Src/umathmodule.obj up-
to-date)
D:\Program Files\Microsoft Visual Studio\VC98\BIN\link.exe /DLL /nologo
/INCREME
NTAL:NO /LIBPATH:D:\python20\libs m.lib /EXPORT:initumath
build\temp.win32-2.0\R
elease\Src/umathmodule.obj /OUT:build\lib.win32-2.0\umath.pyd
/IMPLIB:build\temp
.win32-2.0\Release\Src\umath.lib
LINK : fatal error LNK1181: cannot open input file "m.lib"
error: command '"D:\Program Files\Microsoft Visual
Studio\VC98\BIN\link.exe"' failed with exit status 1181

I would like that somebody would let me know when it is fixed.
And if possible, I would like to know about your plans conserning bug
#122395

my E-mail is: sveta@camelot.com
-------------------------------

Thank you,
Just one more thing:
I also tried several times to get registered here in order to be informed
about bugs, but for unknown reason it never works.
That's what I get after I enter all details needed for making a new
account:

The page cannot be displayed 
The page you are looking for is currently unavailable. The Web site might
be experiencing technical difficulties, or you may need to adjust your
browser settings. 

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

Please try the following:

Click the  Refresh button, or try again later.

"
If you typed the page address in the Address bar, make sure that it is
spelled correctly.

To check your connection settings, click the Tools menu, and then click
Internet Options. On the Connections tab, click Settings. The settings
should match those provided by your local area network (LAN) administrator
or Internet service provider (ISP). 
If your Network Administrator has enabled it, Microsoft Windows can examine
your network and automatically discover network connection settings.
If you would like Windows to try and discover them, 
click  Detect Network Settings 
Some sites require 128-bit connection security. Click the Help menu and
then click About Internet Explorer to determine what strength security you
have installed. 
If you are trying to reach a secure site, make sure your Security settings
can support it. Click the Tools menu, and then click Internet Options. On
the Advanced tab, scroll to the Security section and check settings for SSL
2.0, SSL 3.0, TLS 1.0, PCT 1.0. 
Click the  Back button to try another link. 

Cannot find server or DNS Error
Internet Explorer  
"

Why is that???

Thank you,
Svetlana.

my E-mail is: sveta@camelot.com
-------------------------------



Follow-Ups:

Date: 2001-Feb-14 09:40
By: akuchling

Comment:
This seems fairly clearly to be a problem with Numeric's 
setup script, which specifies the 'm' library as required
for the umath module; presumably this library doesn't exist on Windows.

Please report this to the Numeric Python bug tracker
at http://sourceforge.net/bugs/?group_id=1369
-------------------------------------------------------

Date: 2001-Feb-09 15:55
By: tim_one

Comment:
Assigned to Andrew because he's attracted to hairy installation problems.

Svetlana, sorry you haven't been able to register on SourceForge yet. 
Unfortunately, we don't run or control this site, we're just hosted at
SourceForge.  If your problems persist, you'll have to file a bug with
SourceForge itself:

https://sourceforge.net/bugs/?group_id=1

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131398&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 21:12:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 13:12:07 -0800
Subject: [Python-bugs-list] [Bug #132397] 2.0 doesn't install libpython2.0.a
Message-ID: <E14T9Db-0004K0-00@usw-sf-web1.sourceforge.net>

Bug #132397, was updated on 2001-Feb-14 13:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: thayer
Assigned to : nobody
Summary: 2.0 doesn't install libpython2.0.a

Details: Under Linux (uname -s) no library gets installed by default. 
There's an
attempt at libpython2.0.so, which doesn't seem to build.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132397&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 21:12:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 13:12:42 -0800
Subject: [Python-bugs-list] [Bug #132398] Emacs Python mode bugs
Message-ID: <E14T9EA-0004KI-00@usw-sf-web1.sourceforge.net>

Bug #132398, was updated on 2001-Feb-14 13:12
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: gvanrossum
Assigned to : bwarsaw
Summary: Emacs Python mode bugs

Details: 1. I wish that Emacs Python mode, when I run a buffer with ^C^C,
looked at the #! line (if there is one) to choose a Python interpreter,
rather than blindly using the default.

2. Also, when I set the variable python-command to "python1.5", this
apparently has no effect -- it still uses "python".

3. Maybe I've submitted this before; each time I use ^C^CF a new buffer
with a name like /usr/tmp/python-uKA1TJ is created; these buffers just
collect dust.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132398&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 21:21:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 13:21:44 -0800
Subject: [Python-bugs-list] [Bug #132397] 2.0 doesn't install libpython2.0.a
Message-ID: <E14T9Mu-0005uC-00@usw-sf-web3.sourceforge.net>

Bug #132397, was updated on 2001-Feb-14 13:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 5
Submitted by: thayer
Assigned to : gvanrossum
Summary: 2.0 doesn't install libpython2.0.a

Details: Under Linux (uname -s) no library gets installed by default. 
There's an
attempt at libpython2.0.so, which doesn't seem to build.


Follow-Ups:

Date: 2001-Feb-14 13:21
By: gvanrossum

Comment:
libpython2.0.a is installed as
<prefix>/lib/python2.0/config/libpython2.0.a.

The .so is a red herring; however check out the 2.1 alpha release (see
python.org) which does things totally different.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132397&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 21:29:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 13:29:38 -0800
Subject: [Python-bugs-list] [Bug #132399] Problem with floats in dictionary values
Message-ID: <E14T9UY-0004hS-00@usw-sf-web2.sourceforge.net>

Bug #132399, was updated on 2001-Feb-14 13:29
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: Problem with floats in dictionary values

Details: Python 2.0 seems to have a bug when using floats as the value in
a
dictionary.  Is there a fix for this that I need?

This is the Python 2.0 version of what I'm doing:

>>> x = {'a':0.4, 'b':0.4, 'c':0.4}
>>> print x
{'b': 0.40000000000000002, 'c': 0.40000000000000002, 'a':
0.40000000000000002}

But, if you just are doing this with normal scalar variables it works
fine.

>>> x = 0.4
>>> print x
0.4

And, notice the difference from the following Python 1.5.2 version below,
which treats the dictionary values correctly.

>>> x = {'a':0.4, 'b':0.4, 'c':0.4}
>>> print x
{'b': 0.4, 'c': 0.4, 'a': 0.4}



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132399&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 21:33:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 13:33:22 -0800
Subject: [Python-bugs-list] [Bug #132399] Problem with floats in dictionary values
Message-ID: <E14T9YA-0005zc-00@usw-sf-web3.sourceforge.net>

Bug #132399, was updated on 2001-Feb-14 13:29
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: Problem with floats in dictionary values

Details: Python 2.0 seems to have a bug when using floats as the value in
a
dictionary.  Is there a fix for this that I need?

This is the Python 2.0 version of what I'm doing:

>>> x = {'a':0.4, 'b':0.4, 'c':0.4}
>>> print x
{'b': 0.40000000000000002, 'c': 0.40000000000000002, 'a':
0.40000000000000002}

But, if you just are doing this with normal scalar variables it works
fine.

>>> x = 0.4
>>> print x
0.4

And, notice the difference from the following Python 1.5.2 version below,
which treats the dictionary values correctly.

>>> x = {'a':0.4, 'b':0.4, 'c':0.4}
>>> print x
{'b': 0.4, 'c': 0.4, 'a': 0.4}



Follow-Ups:

Date: 2001-Feb-14 13:33
By: gvanrossum

Comment:
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

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132399&group_id=5470


From noreply@sourceforge.net  Wed Feb 14 22:16:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 14:16:16 -0800
Subject: [Python-bugs-list] [Bug #132409] setup.py does not look in the right place for xmlparse.h
Message-ID: <E14TADg-00053S-00@usw-sf-web2.sourceforge.net>

Bug #132409, was updated on 2001-Feb-14 14:16
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: ajseward
Assigned to : nobody
Summary: setup.py does not look in the right place for xmlparse.h

Details: Modules/pyexpat.c includes "expat/xmlparse.h" so setup.py should
also look for "expat/xmlparse.h".  Currently pyexpat will not build if
there is not a file named xmlparse.h in the standard include path.

See patch #103804 for a fix


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132409&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 01:22:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 17:22:26 -0800
Subject: [Python-bugs-list] [Bug #132409] setup.py does not look in the right place for xmlparse.h
Message-ID: <E14TD7q-0006Nr-00@usw-sf-web2.sourceforge.net>

Bug #132409, was updated on 2001-Feb-14 14:16
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: ajseward
Assigned to : nobody
Summary: setup.py does not look in the right place for xmlparse.h

Details: Modules/pyexpat.c includes "expat/xmlparse.h" so setup.py should
also look for "expat/xmlparse.h".  Currently pyexpat will not build if
there is not a file named xmlparse.h in the standard include path.

See patch #103804 for a fix


Follow-Ups:

Date: 2001-Feb-14 17:22
By: ajseward

Comment:
Sorry, this was caused by another patch that I had not looked at closely
enough.  There is no problem in the CVS source. 
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132409&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 03:14:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 19:14:29 -0800
Subject: [Python-bugs-list] [Bug #132460] SSL Support (Apparently) Broken on Solaris
Message-ID: <E14TEsH-0003RU-00@usw-sf-web1.sourceforge.net>

Bug #132460, was updated on 2001-Feb-14 19:14
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: beazley
Assigned to : nobody
Summary: SSL Support (Apparently) Broken on Solaris

Details: I have spent about 10 hours banging on this with no luck.

Python   :  Python-2.0
Platform :  SPARC Solaris 2.8
Compiler :  Sun Workshop Pro v5.0, gcc-2.95-2
OpenSSL  :  openssl-0.9.6 and 0.9.5.

Problem -

All attempts to open a SSL connection result in an "SSL_connect error".

I have tried various combinations of keys and certificates.
I have looked at the Python source code extensively and added debugging to
try and get more information.  I have run the system using the openssl
s_client and s_server testing tools.   I have recompiled everything in
various configurations of versions and compilers.  In all cases, the same
error is generated.

That said, has *ANYBODY* gotten this to work on Solaris?  
If so, do you have any details that can be shared?

Cheers,

Dave
  
P.S. I will submit a patch if I can ever get this to actually work.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132460&group_id=5470


From beazley@cs.uchicago.edu  Thu Feb 15 05:18:43 2001
From: beazley@cs.uchicago.edu (David Beazley)
Date: Wed, 14 Feb 2001 23:18:43 -0600 (CST)
Subject: [Python-bugs-list] [Bug #132460] SSL Support (Apparently) Broken on Solaris
In-Reply-To: <E14TEsH-0003RU-00@usw-sf-web1.sourceforge.net>
References: <E14TEsH-0003RU-00@usw-sf-web1.sourceforge.net>
Message-ID: <14987.26291.715378.390634@gargoyle.cs.uchicago.edu>

noreply@sourceforge.net writes:
 >   
 > P.S. I will submit a patch if I can ever get this to actually work.
 > 

A followup on this bug....  It appears that Python is not properly
seeding the OpenSSL random number generator when it creates a secure
socket.  This, in turn, causes the SSL_connect() function to fail due
to improper random number seeding (although the error isn't
obvious--at least not to me).   This is also due to an apparent
"feature" of Solaris not providing a usuable /dev/random device.

A simple fix is to modify init_socket() in socketmodule.c to include
a call to RAND_seed() like this:

#ifdef USE_SSL
        SSL_load_error_strings();
        SSLeay_add_ssl_algorithms();
        /* Sick hack for Solaris */
        {
           char bogus[64];
           /* Fill in bogus with some random noise */
           ...
           RAND_seed(bogus, 64);
        }
        ...
#endif

Presumably one would need to think about the randomness actually
passed to RAND_seed()  (I have done nothing above).

Here are related comments from the OpenSSL FAQ:

"Cryptographic software needs a source of unpredictable data to work
correctly. Many open source operating systems provide a "randomness
device" that serves this purpose. On other systems, applications have
to call the RAND_add() or RAND_seed() function with appropriate data
before generating keys or performing public key encryption.

Some broken applications do not do this. As of version
0.9.5, the OpenSSL functions that need randomness report an error if
the random number generator has not been seeded with at least 128 bits of
randomness. If this error occurs, please contact the author of the
application you are using. It is likely that it never worked
correctly. OpenSSL 0.9.5 and later make the error visible by refusing
to perform potentially insecure encryption."

Python-2.1a2 does not appear to include a fix, but I can't test it to
find out (since 2.1a2 won't compile on my machine).

Cheers,

Dave




From noreply@sourceforge.net  Thu Feb 15 06:37:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 14 Feb 2001 22:37:33 -0800
Subject: [Python-bugs-list] [Bug #131825] doctest.py needs docs
Message-ID: <E14TI2n-0008R0-00@usw-sf-web2.sourceforge.net>

Bug #131825, was updated on 2001-Feb-10 01:03
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: tim_one
Assigned to : fdrake
Summary: doctest.py needs docs

Details: I need to write something up for Fred.  The doctest docstrings are
too much info -- need a much quicker intro for the Library Manual, and
point to the docstrings for unusual cases (I personally almost never use
*any* of the fancy stuff!).


Follow-Ups:

Date: 2001-Feb-14 22:37
By: tim_one

Comment:
Doc, doc!  Who's there?  doctest docs.

https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103808&group_id=5470

Plain ASCII.  See patch comments for other blather.

Assigned to Fred.  But bet he'd like it if someone else with LaTeXification
powers did this.  I'm not mentioning Moshe by name, though.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131825&group_id=5470


From tim.one@home.com  Thu Feb 15 07:56:15 2001
From: tim.one@home.com (Tim Peters)
Date: Thu, 15 Feb 2001 02:56:15 -0500
Subject: [Python-bugs-list] [Bug #132460] SSL Support (Apparently) Broken on Solaris
In-Reply-To: <14987.26291.715378.390634@gargoyle.cs.uchicago.edu>
Message-ID: <LNBBLJKPBEHFEDALKOLCCEIGIPAA.tim.one@home.com>

[David Beazley, SSL hypothesizing]

David, I don't know whether you added this info to the bug report on
SourceForge, but if you didn't it's now lost in a black hole.

i-can-only-afford-to-search-327-archives-per-day-and-the-
    read-only-bug-list-is-#359-ly y'rs  - tim



From noreply@sourceforge.net  Thu Feb 15 10:25:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 02:25:30 -0800
Subject: [Python-bugs-list] [Bug #132493] UserString can not be used as string in calls to C routines
Message-ID: <E14TLbO-0001Sv-00@usw-sf-web2.sourceforge.net>

Bug #132493, was updated on 2001-Feb-15 02:25
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Submitted by: hooft
Assigned to : nobody
Summary: UserString can not be used as string in calls to C routines

Details: schol[53]:ccd>cat uss.py
import os,UserString

a=UserString.UserString('/etc/passwd')

print os.path.exists(a)
schol[54]:ccd>python uss.py
Traceback (most recent call last):
  File "uss.py", line 5, in ?
    print os.path.exists(a)
  File "/usr/local/nonius/lib/python2.0/posixpath.py", line 166, in
exists
    st = os.stat(path)
TypeError: stat, argument 1: expected string, instance found


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132493&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 11:31:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 03:31:23 -0800
Subject: [Python-bugs-list] [Bug #131774] Architecture-specific config.h is badly named
Message-ID: <E14TMd9-0007tj-00@usw-sf-web1.sourceforge.net>

Bug #131774, was updated on 2001-Feb-09 13:57
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Feature Request
Priority: 5
Submitted by: gramirez
Assigned to : twouters
Summary: Architecture-specific config.h is badly named

Details: If Python is installed with architecture-dependent and
architecture-independent files in separate locations (using --prefix and
--exec-prefix), then config.h is placed in a directory different than
Python.h (and pyport.h and pgenheaders.h, which also #include
"config.h").

If I build a python module which has its own config.h (like pygtk), the
build fails because Python.h #include's the *wrong* config.h. I cannot
easily change the order of the
-I flags when compiling pygtk because autoconf places its flags
(AM_CPPFLAGS) before any CPPFLAGS that I define in the CPPFLAGS environment
variable.

It would be cleaner to follow the glib model which names its installed
arch-specific file "glibconfig.h". We could install config.h as
pythonconfig.h, and have Python.h #include "pythonconfig.h"



Follow-Ups:

Date: 2001-Feb-15 03:31
By: twouters

Comment:
I'll do it, but I don't mind if anyone else does it before me (One free
alpha is enough, anyway :-) My main question is: should anybody be
(legitimately) including Python's config.h directly ? I was thinking
'py_acconfig.h' myself, for the new autoconf config.h name. 

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

Date: 2001-Feb-09 16:03
By: tim_one

Comment:
Assigned to Thomas.  Reassign to someone else if you don't want it!  Guido
said he did want it, but didn't bother assigning it to anyone.  Given that
we delayed "in dict", we have to find some other way to justify giving you
a free alpha release <wink>.

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

Date: 2001-Feb-09 14:10
By: gvanrossum

Comment:
Good idea!  Patch anybody?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131774&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 11:33:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 03:33:44 -0800
Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c
Message-ID: <E14TMfQ-0007uj-00@usw-sf-web1.sourceforge.net>

Bug #128973, was updated on 2001-Jan-15 21:12
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: Works For Me
Bug Group: Platform-specific
Priority: 3
Submitted by: jpettit
Assigned to : twouters
Summary: OpenBSD Problems with _funlockfile in fileobject.c

Details: When I compile the current CVS version of Python on OpenBSD 2.8, I
get the following linker error:

    ld: _funlockfile: non-function jmpslot
    collect2: ld returned 1 exit status
    *** Error code 1

This function was first added to Python in version 2.97 of "fileobject.c".

Follow-Ups:

Date: 2001-Feb-15 03:33
By: twouters

Comment:
Lowered priority and set resolution to 'works for me' because it does work
for me. Leaving it open for a bit more, to give jpettit a chance to react
and possibly disagree.

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

Date: 2001-Feb-02 07:54
By: twouters

Comment:
Testing the current CVS tree on ltratt's offered OpenBSD machine
(OpenBSD-stable 2.8 on i386) I can't reproduce the problem. I do see these
slightly suspicious messages though:

ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x2d5ec for
"_flockfile"
ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x2d633 for
"_funlockfile"

I suspect this is fixed by an update/patch/whatever OpenBSD uses to one of
the development tools (gcc, ld, libc, whatever OpenBSD uses :)
Unless there was some other difference between the machines of jpettit and
ltratt ?

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

Date: 2001-Feb-02 07:34
By: twouters

Comment:
I've volunteered myself to debug this, on OpenBSD, using the provided
account.



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

Date: 2001-Jan-25 10:38
By: ltratt

Comment:
I'd be happy to offer any of the Python developers an account on an OpenBSD
machine if they wish - mail tratt@dcs.kcl.ac.uk
-------------------------------------------------------

Date: 2001-Jan-18 19:32
By: gvanrossum

Comment:
Alas, it seems that this will remain open in 2.1a1.  Hopefully someone else
will be able to fix it once the alpha1 release is out.

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

Date: 2001-Jan-16 11:58
By: jpettit

Comment:
The man page doesn't seem to specify a particular library to link against. 
It only says to include stdio.h.

I'm building Python without any special flags.  I thought threads were
enabled by default, but just for good measure, I ran configure with
--with-threads and got the same results.

I don't see any reference to flockfile/funlockfile in config.log.
-------------------------------------------------------

Date: 2001-Jan-16 11:00
By: twouters

Comment:
Unfortunately, I don't have access to OpenBSD, just FreeBSD and BSDI.
flockfile/funlockfile both work fine there. I suspect it's a header/library
problem: maybe we need to include a separate header/library, which we for
some reason do in the configure process, but not in the linking of Python
(or maybe it needs additional magic to link together with other libraries,
I don't know.)

jpettit, can you check the manpage for funlockfile to see what headerfiles
should be included, and perhaps what to link with ? Also, are you compiling
threaded or unthreaded ? There is a good chance the flockfile/funlockfile
functions are only available in threaded code, or maybe Python is being
compiled half-threaded for some reason. Checking to see the difference
between what config.log and 'make' say might give some hints, too.

Or it could just be an OS bug :P We should be able to figure it out though:
if Python can't *compile* with those functions, neither should configure.

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

Date: 2001-Jan-16 09:56
By: jpettit

Comment:
I'd be happy to help however I can.  However, autoconf is black magic to
me.  

I think that funlockfile is supposed to be available...there is even a man
page dated 20 August 1998.  This may be another case of OpenBSD improperly
integrating components from the other BSDs.

Please let me know what I can do.
-------------------------------------------------------

Date: 2001-Jan-16 05:28
By: gvanrossum

Comment:
It's gotta be more complicated that that.  The configure script has a test
program that calls flockfile(), getc_unlocked(), and funlockfile().  Only
if this test program links successfully does it decide to use
getc_unlocked().  (Making the test depend on successfully *running* it
shouldn't make a difference -- the user here got a link-time error.)

jpettit, is there a way you could find out why the configure test succeeds
but then you get a link error linking Python?

I'll also ask Thomas Wouters to look into this.

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

Date: 2001-Jan-15 22:19
By: tim_one

Comment:
Ho ho ho:  so this means some flavor of Unix has getc_unlocked() but not
the flockfile() and funlockfile() that are supposed to come with it?  Man,
Windows looks better every day <wink> -- and so does the
getline_via_fgets() hack ...

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 11:47:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 03:47:43 -0800
Subject: [Python-bugs-list] [Bug #129995] segfaults on AIX if configured with threads
Message-ID: <E14TMsx-0001zV-00@usw-sf-web2.sourceforge.net>

Bug #129995, was updated on 2001-Jan-24 16:44
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: bcollar
Assigned to : twouters
Summary: segfaults on AIX if configured with threads

Details: Hi. AIX 4.2.1. ran ./configure --without-gcc
--prefix=/development/utils. make CC=xlC OPT="-O2 -qmaxmem=4000". some of
the make output follows. Let me know if you need all of it.

if test ! -f ../Modules/hassignal;  then echo adding sigcheck.o; ar r
../libpython2.1.a sigcheck.o;  else echo leaving sigcheck.o out; fi
leaving sigcheck.o out
        touch add2lib
        if test -f hassignal;  then echo removing sigcheck.o intrcheck.o; 
ar d ../libpython2.1.a sigcheck.o intrcheck.o 2>/dev/null;  else echo
leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
make: 1254-004 The error code from the last command is 2.
make: 1254-005 Ignored error code 2 from last command.
        ar cr ../libpython2.1.a gcmodule.o  threadmodule.o  posixmodule.o 
_sre.o  signalmodule.o config.o getpath.o main.o getbuildinfo.o
        touch add2lib
        cd Modules; make OPT="-O2 -qmaxmem=4000" python.o
        xlC -O2 -qmaxmem=4000 -I./../Include -I.. -DHAVE_CONFIG_H -c
python.c
        expr `cat buildno` + 1 >buildno1
        mv -f buildno1 buildno
        xlC -c -O2 -qmaxmem=4000 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno` 
./Modules/getbuildinfo.c
        ar cr libpython2.1.a getbuildinfo.o
        ranlib libpython2.1.a
        true
        cd Modules;  make OPT="-O2 -qmaxmem=4000" VERSION="2.1" 
prefix="/development/utils/" exec_prefix="/development/utils/" 
LIBRARY=../libpython2.1.a link
        ./makexp_aix python.exp "" ../libpython2.1.a;  xlC 
-Wl,-bE:python.exp -lld python.o  ../libpython2.1.a   -ldl  -lpthreads -lm 
-o python 
        mv python ../python
        ./python ./setup.py build
pthread_mutex_init: Error 0
pthread_cond_init: Error 0
pthread_mutex_lock[1]: Error 0
make: 1254-059 The signal code from the last command is 11.


Follow-Ups:

Date: 2001-Feb-15 03:47
By: twouters

Comment:
I've rewritten the AIX blurb to mention cc_r (or any threadsafe compiler,
really) even when not compiling for C++ support.
bcollar, does using cc_r (or xlC_r) instead of xlC fix your problem ?


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

Date: 2001-Feb-06 09:18
By: donnc

Comment:
Instead of xlC,  use cc_r.  That (on my host anyway) is
the xlC.cfg compiler configuration that uses the reentrant
libraries for thread support, which are not the default.
-------------------------------------------------------

Date: 2001-Feb-02 05:59
By: twouters

Comment:
I'd like to note that though I don't have access to AIX myself, I do live
with and share a bed with a system administrator who does, very much so,
many, many hours per week. She doesn't have a *compiler* on AIX, though, so
more than general AIX info and the odd programmers manual is out of the
question.

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

Date: 2001-Feb-01 09:21
By: bwarsaw

Comment:
Assigning this to Thomas, since I don't have an AIX machine handy, and he
made the mistake of chiming in. :)
-------------------------------------------------------

Date: 2001-Feb-01 06:53
By: twouters

Comment:
Try making sure configure itself is also run with the same CC and OPT
arguments, by running configure like this (using (ba)sh syntax, should work
in ksh as well):

CC=xlC CFLAGS="-O2 -qmaxmem=4000" ./configure <normalopts>

configure might be mis-detecting some things because of the different
arguments.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129995&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 13:33:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 05:33:08 -0800
Subject: [Python-bugs-list] [Bug #132510] Fatal error on x+1=1
Message-ID: <E14TOWy-0002ie-00@usw-sf-web2.sourceforge.net>

Bug #132510, was updated on 2001-Feb-15 05:33
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 8
Submitted by: gvanrossum
Assigned to : jhylton
Summary: Fatal error on x+1=1

Details: The statement x+1=1 causes the code generator to dump some
internal data structures and issue a fatal error:
too many children in default case.  The dump says:
300: (null)
  301: (null)
    302: (null)
      303: (null)
        304: (null)
          1: x
  14: +
  301: (null)
    302: (null)
      303: (null)
        304: (null)
          2: 1



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132510&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 13:35:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 05:35:00 -0800
Subject: [Python-bugs-list] [Bug #114557] Nuke hard tabs from the std library
Message-ID: <E14TOYm-0000an-00@usw-sf-web1.sourceforge.net>

Bug #114557, was updated on 2000-Sep-15 18:59
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 5
Submitted by: tim_one
Assigned to : tim_one
Summary: Nuke hard tabs from the std library

Details: It was agreed for 2.0b1 that all std libraries modules would use
4-space indents and no hard tabs.  This didn't happen, due to a
misunderstanding.  Repair that after 2.0final is released (would be sooner,
except about 250 files are affected, and that much fiddling carries some
risk).

Follow-Ups:

Date: 2001-Feb-15 05:34
By: gvanrossum

Comment:
This was done for 2.1!
-------------------------------------------------------

Date: 2000-Sep-15 19:18
By: tim_one

Comment:
Forgot to close it.
-------------------------------------------------------

Date: 2000-Sep-15 19:01
By: tim_one

Comment:
Moved to PEP42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114557&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 13:40:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 05:40:17 -0800
Subject: [Python-bugs-list] [Bug #132493] UserString can not be used as string in calls to C routines
Message-ID: <E14TOdt-0006GR-00@usw-sf-web3.sourceforge.net>

Bug #132493, was updated on 2001-Feb-15 02:25
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Submitted by: hooft
Assigned to : gvanrossum
Summary: UserString can not be used as string in calls to C routines

Details: schol[53]:ccd>cat uss.py
import os,UserString

a=UserString.UserString('/etc/passwd')

print os.path.exists(a)
schol[54]:ccd>python uss.py
Traceback (most recent call last):
  File "uss.py", line 5, in ?
    print os.path.exists(a)
  File "/usr/local/nonius/lib/python2.0/posixpath.py", line 166, in
exists
    st = os.stat(path)
TypeError: stat, argument 1: expected string, instance found


Follow-Ups:

Date: 2001-Feb-15 05:40
By: gvanrossum

Comment:
Alas, this is true.  The same holds for UserDict and UserList.

There is no easy fix.

Fixing this will be a major project, probably for Python 3000.

I'm adding a reminder to PEP 42, and closing the bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132493&group_id=5470


From beazley@cs.uchicago.edu  Thu Feb 15 14:03:48 2001
From: beazley@cs.uchicago.edu (David Beazley)
Date: Thu, 15 Feb 2001 08:03:48 -0600 (CST)
Subject: [Python-bugs-list] [Bug #132460] SSL Support (Apparently) Broken on Solaris
In-Reply-To: <LNBBLJKPBEHFEDALKOLCCEIGIPAA.tim.one@home.com>
References: <14987.26291.715378.390634@gargoyle.cs.uchicago.edu>
 <LNBBLJKPBEHFEDALKOLCCEIGIPAA.tim.one@home.com>
Message-ID: <14987.57796.87615.134772@gargoyle.cs.uchicago.edu>

Tim Peters writes:
 > [David Beazley, SSL hypothesizing]
 > 
 > David, I don't know whether you added this info to the bug report on
 > SourceForge, but if you didn't it's now lost in a black hole.
 > 

I will check.   If not, I'll resubmit it through the web (I think I
still have a copy of the followup).

Cheers,

Dave



From noreply@sourceforge.net  Thu Feb 15 14:12:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 06:12:38 -0800
Subject: [Python-bugs-list] [Bug #132460] SSL Support (Apparently) Broken on Solaris
Message-ID: <E14TP9C-00030U-00@usw-sf-web2.sourceforge.net>

Bug #132460, was updated on 2001-Feb-14 19:14
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: beazley
Assigned to : nobody
Summary: SSL Support (Apparently) Broken on Solaris

Details: I have spent about 10 hours banging on this with no luck.

Python   :  Python-2.0
Platform :  SPARC Solaris 2.8
Compiler :  Sun Workshop Pro v5.0, gcc-2.95-2
OpenSSL  :  openssl-0.9.6 and 0.9.5.

Problem -

All attempts to open a SSL connection result in an "SSL_connect error".

I have tried various combinations of keys and certificates.
I have looked at the Python source code extensively and added debugging to
try and get more information.  I have run the system using the openssl
s_client and s_server testing tools.   I have recompiled everything in
various configurations of versions and compilers.  In all cases, the same
error is generated.

That said, has *ANYBODY* gotten this to work on Solaris?  
If so, do you have any details that can be shared?

Cheers,

Dave
  
P.S. I will submit a patch if I can ever get this to actually work.

Follow-Ups:

Date: 2001-Feb-15 06:12
By: beazley

Comment:
A followup on this bug....  It appears that Python is not properly
seeding the OpenSSL random number generator when it creates a secure
socket.  This, in turn, causes the SSL_connect() function to fail due
to improper random number seeding (although the error wasn't
obvious--at least not to me).   This is also due to an apparent
"feature" of Solaris not providing a usable /dev/random device.
 
A simple fix is to modify init_socket() in socketmodule.c to include
a call to RAND_seed() like this:                                     

#ifdef USE_SSL
        SSL_load_error_strings();
        SSLeay_add_ssl_algorithms();
        /* Sick hack for Solaris */
        {
           char bogus[64];
           /* Fill in bogus with some random noise */
           ...
           RAND_seed(bogus, 64);
        }
        ...
#endif
 
Presumably one would need to think about the randomness actually
passed to RAND_seed()  (I have done nothing above).                   


Here are related comments from the OpenSSL FAQ: 

"Cryptographic software needs a source of unpredictable data to work
correctly. Many open source operating systems provide a "randomness
device" that serves this purpose. On other systems, applications have
to call the RAND_add() or RAND_seed() function with appropriate data
before generating keys or performing public key encryption.     

Some broken applications do not do this. As of version
0.9.5, the OpenSSL functions that need randomness report an error if
the random number generator has not been seeded with at least 128 bits of
randomness. If this error occurs, please contact the author of the
application you are using. It is likely that it never worked
correctly. OpenSSL 0.9.5 and later make the error visible by refusing
to perform potentially insecure encryption."
 
Python-2.1a2 does not appear to include a fix, but I can't test it to
find out (since 2.1a2 doesn't compile on my machine).                   

Cheers,

Dave

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132460&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 15:28:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 07:28:38 -0800
Subject: [Python-bugs-list] [Bug #132493] UserString can not be used as string in calls to C routines
Message-ID: <E14TQKk-00077h-00@usw-sf-web3.sourceforge.net>

Bug #132493, was updated on 2001-Feb-15 02:25
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Later
Bug Group: Feature Request
Priority: 5
Submitted by: hooft
Assigned to : gvanrossum
Summary: UserString can not be used as string in calls to C routines

Details: schol[53]:ccd>cat uss.py
import os,UserString

a=UserString.UserString('/etc/passwd')

print os.path.exists(a)
schol[54]:ccd>python uss.py
Traceback (most recent call last):
  File "uss.py", line 5, in ?
    print os.path.exists(a)
  File "/usr/local/nonius/lib/python2.0/posixpath.py", line 166, in
exists
    st = os.stat(path)
TypeError: stat, argument 1: expected string, instance found


Follow-Ups:

Date: 2001-Feb-15 07:28
By: hooft

Comment:
When I submitted the bug, I thought it was very difficult. But
I think there is a bit hackish way to solve it for the UserString.

PyArg_ParseTuple could check for UserString objects if 
a "s" variable is asked for, and return the .data attribute.

Sorry for even proposing it. I'll wait for 3000....
-------------------------------------------------------

Date: 2001-Feb-15 05:40
By: gvanrossum

Comment:
Alas, this is true.  The same holds for UserDict and UserList.

There is no easy fix.

Fixing this will be a major project, probably for Python 3000.

I'm adding a reminder to PEP 42, and closing the bug report.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132493&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 19:20:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 11:20:15 -0800
Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c
Message-ID: <E14TTwt-0005Rw-00@usw-sf-web2.sourceforge.net>

Bug #128973, was updated on 2001-Jan-15 21:12
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: Works For Me
Bug Group: Platform-specific
Priority: 3
Submitted by: jpettit
Assigned to : twouters
Summary: OpenBSD Problems with _funlockfile in fileobject.c

Details: When I compile the current CVS version of Python on OpenBSD 2.8, I
get the following linker error:

    ld: _funlockfile: non-function jmpslot
    collect2: ld returned 1 exit status
    *** Error code 1

This function was first added to Python in version 2.97 of "fileobject.c".

Follow-Ups:

Date: 2001-Feb-15 11:20
By: jpettit

Comment:
Sorry!  I've been slammed at work.  Yes, it compiles cleanly now. 
Unfortunately, it hangs on "test_long" when I run "make test", but this is
documented in "README" as probably being a compiler error.  If I find
anything else, I'll file a new bug report.  Thanks for your help!
-------------------------------------------------------

Date: 2001-Feb-15 03:33
By: twouters

Comment:
Lowered priority and set resolution to 'works for me' because it does work
for me. Leaving it open for a bit more, to give jpettit a chance to react
and possibly disagree.

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

Date: 2001-Feb-02 07:54
By: twouters

Comment:
Testing the current CVS tree on ltratt's offered OpenBSD machine
(OpenBSD-stable 2.8 on i386) I can't reproduce the problem. I do see these
slightly suspicious messages though:

ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x2d5ec for
"_flockfile"
ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x2d633 for
"_funlockfile"

I suspect this is fixed by an update/patch/whatever OpenBSD uses to one of
the development tools (gcc, ld, libc, whatever OpenBSD uses :)
Unless there was some other difference between the machines of jpettit and
ltratt ?

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

Date: 2001-Feb-02 07:34
By: twouters

Comment:
I've volunteered myself to debug this, on OpenBSD, using the provided
account.



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

Date: 2001-Jan-25 10:38
By: ltratt

Comment:
I'd be happy to offer any of the Python developers an account on an OpenBSD
machine if they wish - mail tratt@dcs.kcl.ac.uk
-------------------------------------------------------

Date: 2001-Jan-18 19:32
By: gvanrossum

Comment:
Alas, it seems that this will remain open in 2.1a1.  Hopefully someone else
will be able to fix it once the alpha1 release is out.

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

Date: 2001-Jan-16 11:58
By: jpettit

Comment:
The man page doesn't seem to specify a particular library to link against. 
It only says to include stdio.h.

I'm building Python without any special flags.  I thought threads were
enabled by default, but just for good measure, I ran configure with
--with-threads and got the same results.

I don't see any reference to flockfile/funlockfile in config.log.
-------------------------------------------------------

Date: 2001-Jan-16 11:00
By: twouters

Comment:
Unfortunately, I don't have access to OpenBSD, just FreeBSD and BSDI.
flockfile/funlockfile both work fine there. I suspect it's a header/library
problem: maybe we need to include a separate header/library, which we for
some reason do in the configure process, but not in the linking of Python
(or maybe it needs additional magic to link together with other libraries,
I don't know.)

jpettit, can you check the manpage for funlockfile to see what headerfiles
should be included, and perhaps what to link with ? Also, are you compiling
threaded or unthreaded ? There is a good chance the flockfile/funlockfile
functions are only available in threaded code, or maybe Python is being
compiled half-threaded for some reason. Checking to see the difference
between what config.log and 'make' say might give some hints, too.

Or it could just be an OS bug :P We should be able to figure it out though:
if Python can't *compile* with those functions, neither should configure.

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

Date: 2001-Jan-16 09:56
By: jpettit

Comment:
I'd be happy to help however I can.  However, autoconf is black magic to
me.  

I think that funlockfile is supposed to be available...there is even a man
page dated 20 August 1998.  This may be another case of OpenBSD improperly
integrating components from the other BSDs.

Please let me know what I can do.
-------------------------------------------------------

Date: 2001-Jan-16 05:28
By: gvanrossum

Comment:
It's gotta be more complicated that that.  The configure script has a test
program that calls flockfile(), getc_unlocked(), and funlockfile().  Only
if this test program links successfully does it decide to use
getc_unlocked().  (Making the test depend on successfully *running* it
shouldn't make a difference -- the user here got a link-time error.)

jpettit, is there a way you could find out why the configure test succeeds
but then you get a link error linking Python?

I'll also ask Thomas Wouters to look into this.

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

Date: 2001-Jan-15 22:19
By: tim_one

Comment:
Ho ho ho:  so this means some flavor of Unix has getc_unlocked() but not
the flockfile() and funlockfile() that are supposed to come with it?  Man,
Windows looks better every day <wink> -- and so does the
getline_via_fgets() hack ...

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 20:35:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 12:35:19 -0800
Subject: [Python-bugs-list] [Bug #132597] 2.1a2 compiler warnings on Compaq Tru64 Unix
Message-ID: <E14TV7X-00015X-00@usw-sf-web3.sourceforge.net>

Bug #132597, was updated on 2001-Feb-15 12:35
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 compiler warnings on Compaq Tru64 Unix

Details: 2.1a2 from CVS of Feb 16 produces the following compiler warnings
on Tru64
Unix (uname -a: OSF1 gonzo.per.dem.csiro.au V4.0 1229 alpha, Compaq C
compiler, version: Compaq C V6.3-129 (dtk), Compiler Driver V6.3-126
(dtk)):

cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Python/ceval.o
Python/ceval.c
cc: Info: Python/ceval.c, line 327: Trailing comma found in enumerator
list. (trailcomma)
};


cc -O -Olimit 1500 -I. -I./Include -IInclude/ -I/usr/local/include -c
Modules/_cursesmodule.c -o build/temp.osf1-V4.0-alpha-2.1/_cursesmodule.o
cc: Warning: Modules/_cursesmodule.c, line 632: In this statement,
"derwin(...)" of type "int", is being converted to "pointer to struct
_win_st". (cvtdiftypes)
  win = derwin(self->win,nlines,ncols,begin_y,begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1287: In this statement,
"subpad(...)" of type "int", is being converted to "pointer to struct
_win_st". (cvtdiftypes)
    win = subpad(self->win, nlines, ncols, begin_y, begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1517: In this statement,
"termname(...)" of type "int", is being converted to "pointer to const
char". (cvtdiftypes)
NoArgReturnStringFunction(termname)

cc: Warning: Modules/_cursesmodule.c, line 1686: In this statement,
"getwin(...)" of type "int", is being converted to "pointer to struct
_win_st". (cvtdiftypes)
  win = getwin(PyFile_AsFile(temp));

cc: Warning: Modules/_cursesmodule.c, line 1954: In this statement,
"keyname(...)" of type "int", is being converted to "pointer to const
char". (cvtdiftypes)
  knp = keyname(ch);

cc: Warning: Modules/_cursesmodule.c, line 2245: In this statement,
"tigetstr(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
        capname = tigetstr( capname );

cc: Warning: Modules/_cursesmodule.c, line 2270: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt);

cc: Warning: Modules/_cursesmodule.c, line 2273: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1);

cc: Warning: Modules/_cursesmodule.c, line 2276: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2);

cc: Warning: Modules/_cursesmodule.c, line 2279: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3);

cc: Warning: Modules/_cursesmodule.c, line 2282: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4);

cc: Warning: Modules/_cursesmodule.c, line 2285: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5);

cc: Warning: Modules/_cursesmodule.c, line 2288: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6);

cc: Warning: Modules/_cursesmodule.c, line 2291: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7);

cc: Warning: Modules/_cursesmodule.c, line 2294: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8);

cc: Warning: Modules/_cursesmodule.c, line 2297: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8,i9);

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg1"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg2"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg1"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg2"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg1"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg2"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")






For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132597&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 20:51:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 12:51:03 -0800
Subject: [Python-bugs-list] [Bug #132600] 2.1a2 tries to build bsddb without "-ldb"
Message-ID: <E14TVMl-0001Dv-00@usw-sf-web3.sourceforge.net>

Bug #132600, was updated on 2001-Feb-15 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 tries to build bsddb without "-ldb"

Details: Platform: Tru64 Unix, V4.0F, Compaq C compiler version: Compaq C
V6.3-129 (dtk) on Digital UNIX V4.0F  (Rev. 1229), Compiler Driver V6.3-126
(dtk)

"make" causes setup.py to generate the following compile/link lines for the
bsddb extension:

cc -O -Olimit 1500 -I.
-I/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include -c
/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/Modules/bsddbmodule.c
-o build/temp.osf1-V4.0-alpha-2.1/bsddbmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V4.0-alpha-2.1/bsddbmodule.o -L/usr/local/lib -o
build/lib.osf1-V4.0-alpha-2.1/bsddb.so

The lack of a "-ldb" in the ld command causes "make test" to skip the bsddb
test (and "import bsddb" to fail) due to unresolved symbols. Looking at the
code in setup.py, the "-ldb" is only included if "db_185.h" is found. If
"db.h" is found instead, no "-l" is appended to the link line. Compaq Tru64
comes standard with db (a Compaq-modified 1.85 version, I believe), with
/usr/include/db.h and /usr/lib/libdb.a and /usr/shlib/libdb.so. Manually
adding "-ldb" to the above link line allows test_bsddb to run and pass.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132600&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 21:21:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 13:21:14 -0800
Subject: [Python-bugs-list] [Bug #132606] 2.1a2 _tkinter build may pick up wrong Tcl/Tk versions
Message-ID: <E14TVpy-0001Rn-00@usw-sf-web3.sourceforge.net>

Bug #132606, was updated on 2001-Feb-15 13:21
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 _tkinter build may pick up wrong Tcl/Tk versions

Details: Platform: Compaq Tru64 Unix, Version 4.0F, Compaq C V6.3-129 (dtk)
on Digital UNIX V4.0F  (Rev. 1229), Compiler Driver V6.3-126 (dtk) cc
Driver

setup.py generates the following compile and link lines for _tkinter.c:

cc -O -Olimit 1500 -DWITH_APPINIT=1 -I/usr/X11/include -I.
-I/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include -c
/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/Modules/
_tkinter.c -o build/temp.osf1-V4.0-alpha-2.1/_tkinter.o
cc -O -Olimit 1500 -DWITH_APPINIT=1 -I/usr/X11/include -I.
-I/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include -c
/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/Modules/
tkappinit.c -o build/temp.osf1-V4.0-alpha-2.1/tkappinit.o
ld -shared -expect_unresolved * build/temp.osf1-V4.0-alpha-2.1/_tkinter.o
build/
temp.osf1-V4.0-alpha-2.1/tkappinit.o -L/usr/X11/lib -L/usr/local/lib
-ltk8.0 -lt
cl8.0 -lX11 -o build/lib.osf1-V4.0-alpha-2.1/_tkinter.so

/usr/X11/include precedes /usr/local/include and /usr/X11/lib precedes
/usr/local/lib and will be searched first.  /usr/X11/{include,lib} are,
according to the comment in setup.py, the default location for X11. If a
system comes with Tcl/Tk installed, and the user installs a later version
in /usr/local, setup.py will use the earlier version's include files and
(probably) the later versions library files, assuming the version number is
part of the library filename and "-l{tcl,tk}" string. This mismatch will
not be good... This is the case with Tru64, which comes with an old (7.6)
version of Tcl/Tk. The only reason I didn't fall foul of this gotcha was
that Tru64 doesn't have a /usr/X11 directory - it has the standard (but
probably pre-Linux standard!) /usr/include/X11 and /usr/lib/X11 structure.
I'd suggest that for both the includes and libs /usr/local should appear
before the "default" system X11 directories.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132606&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 21:34:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 13:34:13 -0800
Subject: [Python-bugs-list] [Bug #132609] 2.1a2 possible include/library mismatch in setup.py
Message-ID: <E14TW2X-0005WN-00@usw-sf-web1.sourceforge.net>

Bug #132609, was updated on 2001-Feb-15 13:34
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 possible include/library mismatch in setup.py

Details: The current CVS (Feb 16) version of 2.1a2 has in setup.py the
following:

    def detect_modules(self):
        # Ensure that /usr/local is always used
        if '/usr/local/lib' not in self.compiler.library_dirs:
            self.compiler.library_dirs.append('/usr/local/lib')
        if '/usr/local/include' not in self.compiler.include_dirs:
            self.compiler.include_dirs.append( '/usr/local/include' )

        # lib_dirs and inc_dirs are used to search for files;
        # if a file is found in one of those directories, it can
        # be assumed that no additional -I,-L directives are needed.
        lib_dirs = self.compiler.library_dirs + ['/lib', '/usr/lib']
        inc_dirs = ['/usr/include'] + self.compiler.include_dirs

Naively, it seems to me that the lib_dirs line should read:
inc_dirs = self.compiler.include_dirs + ['/usr/include']
so that /usr/local is searched during the compile/link phases before the
standard system locations. Otherwise, a module could "include" files from
/usr/include and link against library files from /usr/local/lib if a an
earlier version of some software package was bundled with the OS (and was
in /usr/include, /usr/lib) and a later version had been installed in
/usr/local/{include, lib}.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132609&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 22:32:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 14:32:37 -0800
Subject: [Python-bugs-list] [Bug #132619] 2.1a2 misleading comment from "make install" (minor nit)
Message-ID: <E14TWx3-0006uV-00@usw-sf-web2.sourceforge.net>

Bug #132619, was updated on 2001-Feb-15 14:32
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 misleading comment from "make install" (minor nit)

Details: 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.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132619&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 23:26:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 15:26:55 -0800
Subject: [Python-bugs-list] [Bug #129995] segfaults on AIX if configured with threads
Message-ID: <E14TXnb-0002Oo-00@usw-sf-web3.sourceforge.net>

Bug #129995, was updated on 2001-Jan-24 16:44
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: bcollar
Assigned to : twouters
Summary: segfaults on AIX if configured with threads

Details: Hi. AIX 4.2.1. ran ./configure --without-gcc
--prefix=/development/utils. make CC=xlC OPT="-O2 -qmaxmem=4000". some of
the make output follows. Let me know if you need all of it.

if test ! -f ../Modules/hassignal;  then echo adding sigcheck.o; ar r
../libpython2.1.a sigcheck.o;  else echo leaving sigcheck.o out; fi
leaving sigcheck.o out
        touch add2lib
        if test -f hassignal;  then echo removing sigcheck.o intrcheck.o; 
ar d ../libpython2.1.a sigcheck.o intrcheck.o 2>/dev/null;  else echo
leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
make: 1254-004 The error code from the last command is 2.
make: 1254-005 Ignored error code 2 from last command.
        ar cr ../libpython2.1.a gcmodule.o  threadmodule.o  posixmodule.o 
_sre.o  signalmodule.o config.o getpath.o main.o getbuildinfo.o
        touch add2lib
        cd Modules; make OPT="-O2 -qmaxmem=4000" python.o
        xlC -O2 -qmaxmem=4000 -I./../Include -I.. -DHAVE_CONFIG_H -c
python.c
        expr `cat buildno` + 1 >buildno1
        mv -f buildno1 buildno
        xlC -c -O2 -qmaxmem=4000 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno` 
./Modules/getbuildinfo.c
        ar cr libpython2.1.a getbuildinfo.o
        ranlib libpython2.1.a
        true
        cd Modules;  make OPT="-O2 -qmaxmem=4000" VERSION="2.1" 
prefix="/development/utils/" exec_prefix="/development/utils/" 
LIBRARY=../libpython2.1.a link
        ./makexp_aix python.exp "" ../libpython2.1.a;  xlC 
-Wl,-bE:python.exp -lld python.o  ../libpython2.1.a   -ldl  -lpthreads -lm 
-o python 
        mv python ../python
        ./python ./setup.py build
pthread_mutex_init: Error 0
pthread_cond_init: Error 0
pthread_mutex_lock[1]: Error 0
make: 1254-059 The signal code from the last command is 11.


Follow-Ups:

Date: 2001-Feb-15 15:26
By: bcollar

Comment:
Response to twouters' question: yes, the error is fixed when using cc_r.


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

Date: 2001-Feb-15 03:47
By: twouters

Comment:
I've rewritten the AIX blurb to mention cc_r (or any threadsafe compiler,
really) even when not compiling for C++ support.
bcollar, does using cc_r (or xlC_r) instead of xlC fix your problem ?


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

Date: 2001-Feb-06 09:18
By: donnc

Comment:
Instead of xlC,  use cc_r.  That (on my host anyway) is
the xlC.cfg compiler configuration that uses the reentrant
libraries for thread support, which are not the default.
-------------------------------------------------------

Date: 2001-Feb-02 05:59
By: twouters

Comment:
I'd like to note that though I don't have access to AIX myself, I do live
with and share a bed with a system administrator who does, very much so,
many, many hours per week. She doesn't have a *compiler* on AIX, though, so
more than general AIX info and the odd programmers manual is out of the
question.

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

Date: 2001-Feb-01 09:21
By: bwarsaw

Comment:
Assigning this to Thomas, since I don't have an AIX machine handy, and he
made the mistake of chiming in. :)
-------------------------------------------------------

Date: 2001-Feb-01 06:53
By: twouters

Comment:
Try making sure configure itself is also run with the same CC and OPT
arguments, by running configure like this (using (ba)sh syntax, should work
in ksh as well):

CC=xlC CFLAGS="-O2 -qmaxmem=4000" ./configure <normalopts>

configure might be mis-detecting some things because of the different
arguments.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129995&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 23:32:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 15:32:32 -0800
Subject: [Python-bugs-list] [Bug #132633] modules not building on AIX 4.2.1
Message-ID: <E14TXt2-0002RF-00@usw-sf-web3.sourceforge.net>

Bug #132633, was updated on 2001-Feb-15 15:32
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: bcollar
Assigned to : nobody
Summary: modules not building on AIX 4.2.1

Details: Hello

ran:

CC=cc_r CFLAGS="-O2 -qmaxmem=6000" ./configure --without-gcc
--prefix=/development/utils and 
make CC=cc_r OPT="-O2 -qmaxmem=6000" on 2.1a2 code patched with 103679 and
two manual additions in the Makefile so ld_so_aix and makexp_aix are found
(these last two things were committed into CVS, but I forget the patch
numbers...).
Python itself builds fine, but the following occurs when building any
module:

building 'fpectl' extension
skipping /tmp/python/python/dist/src/Modules/fpectlmodule.c
(build/temp.aix-2-000310094C00-2.1/fpectlmodule.o up-to-date)
@BLDSHARED@ build/temp.aix-2-000310094C00-2.1/fpectlmodule.o
-L/usr/local/lib -o build/lib.aix-2-000310094C00-2.1/fpectl.so
unable to execute @BLDSHARED@: No such file or directory


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132633&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 23:52:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 15:52:08 -0800
Subject: [Python-bugs-list] [Bug #132633] modules not building on AIX 4.2.1
Message-ID: <E14TYC0-0002aV-00@usw-sf-web3.sourceforge.net>

Bug #132633, was updated on 2001-Feb-15 15:32
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: bcollar
Assigned to : nobody
Summary: modules not building on AIX 4.2.1

Details: Hello

ran:

CC=cc_r CFLAGS="-O2 -qmaxmem=6000" ./configure --without-gcc
--prefix=/development/utils and 
make CC=cc_r OPT="-O2 -qmaxmem=6000" on 2.1a2 code patched with 103679 and
two manual additions in the Makefile so ld_so_aix and makexp_aix are found
(these last two things were committed into CVS, but I forget the patch
numbers...).
Python itself builds fine, but the following occurs when building any
module:

building 'fpectl' extension
skipping /tmp/python/python/dist/src/Modules/fpectlmodule.c
(build/temp.aix-2-000310094C00-2.1/fpectlmodule.o up-to-date)
@BLDSHARED@ build/temp.aix-2-000310094C00-2.1/fpectlmodule.o
-L/usr/local/lib -o build/lib.aix-2-000310094C00-2.1/fpectl.so
unable to execute @BLDSHARED@: No such file or directory


Follow-Ups:

Date: 2001-Feb-15 15:52
By: bcollar

Comment:
aw crap, that was my fault, sorry! please disregard this bug
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132633&group_id=5470


From noreply@sourceforge.net  Thu Feb 15 23:59:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 15:59:44 -0800
Subject: [Python-bugs-list] [Bug #132637] can't compile modules on AIX 4.2.1 (for real this time)
Message-ID: <E14TYJM-0002dt-00@usw-sf-web3.sourceforge.net>

Bug #132637, was updated on 2001-Feb-15 15:59
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: bcollar
Assigned to : nobody
Summary: can't compile modules on AIX 4.2.1 (for real this time)

Details: Hi,

CC=cc_r CFLAGS="-O2 -qmaxmem=6000" ./configure --prefix=/development/utils
--without-gcc
make CC=cc_r OPT="-O2 -qmaxmem=6000".

I'm building 2.1a2 with patch 103679 applied (necessary for makexp_aix and
ld_so_aix to be found earlier in the process). Here's some output (it's the
same for all modules):

building '_tkinter' extension
/development/utils/lib/python2.1/config/ld_so_aix cc
-bI:/development/utils/lib/python2.1/config/python.exp
build/temp.aix-2-000310094C00-2.1/_tkinter.o
build/temp.aix-2-000310094C00-2.1/tkappinit.o -L/usr/X11/lib
-L/usr/local/lib -ltk8.0 -ltcl8.0 -lld -lX11 -o
build/lib.aix-2-000310094C00-2.1/_tkinter.so
unable to execute /development/utils/lib/python2.1/config/ld_so_aix: No
such file or directory
WARNING: building of extension "_tkinter" failed: command
'/development/utils/lib/python2.1/config/ld_so_aix' failed with exit status
1

There are TWO things I notice here:

1) ld_so_aix is in Modules, not in /development/utils/lib/python2.1/config.
In fact, there is no directory called /development/utils/lib/python2.1.

2) (copied from above)
"/development/utils/lib/python2.1/config/ld_so_aix cc"

Note it says cc, not cc_r, which is how I configured and ran make. cc_r is
darn important, since python will blow up if it's configured with threads
but you don't run cc_r.

Previously this problem was mentioned in bug #129991, which was closed when
I submitted some patches I thought solved the problem...well they were
incomplete. I don't know exactly what to patch for the above problems...


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132637&group_id=5470


From noreply@sourceforge.net  Fri Feb 16 03:05:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 15 Feb 2001 19:05:15 -0800
Subject: [Python-bugs-list] [Bug #131170] make install fails on macosx for Python-2.1a2
Message-ID: <E14TbCt-0000IT-00@usw-sf-web2.sourceforge.net>

Bug #131170, was updated on 2001-Feb-05 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Wont Fix
Bug Group: Platform-specific
Priority: 5
Submitted by: sdm7g
Assigned to : nobody
Summary: make install fails on macosx for Python-2.1a2

Details: Python-2.1a2 on macosx 
make install fails trying to ranlib the shared library:

ranlib: file: /usr/local/lib/python2.1/config/libpython2.1.dylib is not an
archive

(This bug wasn't in 2.0, and I don't think was in 2.1a1.)

-- Steve M.

Follow-Ups:

Date: 2001-Feb-15 19:05
By: nascheme

Comment:
Steve says things are okay if --with-next-framework is
not specified.
-------------------------------------------------------

Date: 2001-Feb-09 15:30
By: tim_one

Comment:
Assigned to Neil for the heck of it.
-------------------------------------------------------

Date: 2001-Feb-07 19:43
By: sdm7g

Comment:
Well, the missing libtool switch to tell it the
library will be installed somewhere else is:

 -install_name  $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to
be unable to find the os.module and sys.path
is set all  wrong. (and it fails somewhere 
else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK
conditional code in getpath.c is getting
the path not from the executable, but from
the library. 

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

Date: 2001-Feb-07 19:42
By: sdm7g

Comment:
Well, the missing libtool switch to tell it the
library will be installed somewhere else is:

 -install_name  $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to
be unable to find the os.module and sys.path
is set all  wrong. (and it fails somewhere 
else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK
conditional code in getpath.c is getting
the path not from the executable, but from
the library. 

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

Date: 2001-Feb-07 19:34
By: sdm7g

Comment:
Well, the missing libtool switch to tell it the
library will be installed somewhere else is:

 -install_name  $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to
be unable to find the os.module and sys.path
is set all  wrong. (and it fails somewhere 
else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK
conditional code in getpath.c is getting
the path not from the executable, but from
the library. 

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

Date: 2001-Feb-07 15:07
By: sdm7g

Comment:
Note: after removing the ranlib, installation succeeds, and the program
works when you are in
the python directory, however, running the installed program from somewhere
else gives the 
fatal error:

dyld: python2.1 can't open library: libpython2.1.dylib  (No such file or
directory, errno = 2)

If you look at the python executable with 
"otool -L" , you can see that system frameworks,
for example, have their complete pathnames, while
libpython2.1.dylib has no path, so it's expected 
in the current directory. 

(looking for the libtool option to correct this...)  -- Steve M. 
-------------------------------------------------------

Date: 2001-Feb-05 13:12
By: nobody

Comment:
Commenting out the $(RANLIB) line in the
install section of Makefile seems to fix the problem on macosx, but I don't
know if it is a problemon any other platforms. 

       @if test -d $(LDLIBRARY); then :; else \
                $(INSTALL_DATA) $(LDLIBRARY) $(LIBPL)/$(LDLIBRARY) ; \
#               $(RANLIB) $(LIBPL)/$(LDLIBRARY) ; \

-- Steve M.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131170&group_id=5470


From noreply@sourceforge.net  Fri Feb 16 08:23:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 00:23:23 -0800
Subject: [Python-bugs-list] [Bug #114557] Nuke hard tabs from the std library
Message-ID: <E14TgAl-0002LR-00@usw-sf-web2.sourceforge.net>

Bug #114557, was updated on 2000-Sep-15 18:59
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Fixed
Bug Group: Feature Request
Priority: 5
Submitted by: tim_one
Assigned to : tim_one
Summary: Nuke hard tabs from the std library

Details: It was agreed for 2.0b1 that all std libraries modules would use
4-space indents and no hard tabs.  This didn't happen, due to a
misunderstanding.  Repair that after 2.0final is released (would be sooner,
except about 250 files are affected, and that much fiddling carries some
risk).

Follow-Ups:

Date: 2001-Feb-16 00:23
By: tim_one

Comment:
Actually, only part of it was done.  The platform-specific libraries were
left untouched (see Python-Dev email).
-------------------------------------------------------

Date: 2001-Feb-15 05:34
By: gvanrossum

Comment:
This was done for 2.1!
-------------------------------------------------------

Date: 2000-Sep-15 19:18
By: tim_one

Comment:
Forgot to close it.
-------------------------------------------------------

Date: 2000-Sep-15 19:01
By: tim_one

Comment:
Moved to PEP42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=114557&group_id=5470


From noreply@sourceforge.net  Fri Feb 16 09:45:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 01:45:07 -0800
Subject: [Python-bugs-list] [Bug #132637] can't compile modules on AIX 4.2.1 (for real this time)
Message-ID: <E14ThRr-0003uM-00@usw-sf-web1.sourceforge.net>

Bug #132637, was updated on 2001-Feb-15 15:59
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: bcollar
Assigned to : nobody
Summary: can't compile modules on AIX 4.2.1 (for real this time)

Details: Hi,

CC=cc_r CFLAGS="-O2 -qmaxmem=6000" ./configure --prefix=/development/utils
--without-gcc
make CC=cc_r OPT="-O2 -qmaxmem=6000".

I'm building 2.1a2 with patch 103679 applied (necessary for makexp_aix and
ld_so_aix to be found earlier in the process). Here's some output (it's the
same for all modules):

building '_tkinter' extension
/development/utils/lib/python2.1/config/ld_so_aix cc
-bI:/development/utils/lib/python2.1/config/python.exp
build/temp.aix-2-000310094C00-2.1/_tkinter.o
build/temp.aix-2-000310094C00-2.1/tkappinit.o -L/usr/X11/lib
-L/usr/local/lib -ltk8.0 -ltcl8.0 -lld -lX11 -o
build/lib.aix-2-000310094C00-2.1/_tkinter.so
unable to execute /development/utils/lib/python2.1/config/ld_so_aix: No
such file or directory
WARNING: building of extension "_tkinter" failed: command
'/development/utils/lib/python2.1/config/ld_so_aix' failed with exit status
1

There are TWO things I notice here:

1) ld_so_aix is in Modules, not in /development/utils/lib/python2.1/config.
In fact, there is no directory called /development/utils/lib/python2.1.

2) (copied from above)
"/development/utils/lib/python2.1/config/ld_so_aix cc"

Note it says cc, not cc_r, which is how I configured and ran make. cc_r is
darn important, since python will blow up if it's configured with threads
but you don't run cc_r.

Previously this problem was mentioned in bug #129991, which was closed when
I submitted some patches I thought solved the problem...well they were
incomplete. I don't know exactly what to patch for the above problems...


Follow-Ups:

Date: 2001-Feb-16 01:45
By: lemburg

Comment:
Ok, here we go again :-)

1)  distutils assumes Python to be already installed on the machine
and thus it looks for the AIX tools in the config dir -- unfortunately,
setup.py is run before these files are installed, so it cannot find
them. Perhaps we ought to add a special case to distutils
which allows finding them anyway ?!

2) It seems as if your make doesn't copy the command line
variables into the OS environment. The setup.py file contains
explicit code which uses the OS environment variables to
choose a compiler and linker:

# When you run "make CC=altcc" or something similar, you really want
# those environment variables passed into the setup.py phase. Here's
# a small set of useful ones.
 compiler = os.environ.get('CC')
 linker_so = os.environ.get('LDSHARED')

Not sure what to do about this. It hints at another problem though:
distutils uses the settings from the Makefile per default. It seems
that in your case it is having trouble parsing that file.

BTW, why does sys.platform return for you ? (There is a switch
in distutils.sysconfig which switches on 'aix4' -- could be that
this causes the problem)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132637&group_id=5470


From noreply@sourceforge.net  Fri Feb 16 09:51:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 01:51:04 -0800
Subject: [Python-bugs-list] [Bug #132637] can't compile modules on AIX 4.2.1 (for real this time)
Message-ID: <E14ThXc-0003xu-00@usw-sf-web1.sourceforge.net>

Bug #132637, was updated on 2001-Feb-15 15:59
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: bcollar
Assigned to : nobody
Summary: can't compile modules on AIX 4.2.1 (for real this time)

Details: Hi,

CC=cc_r CFLAGS="-O2 -qmaxmem=6000" ./configure --prefix=/development/utils
--without-gcc
make CC=cc_r OPT="-O2 -qmaxmem=6000".

I'm building 2.1a2 with patch 103679 applied (necessary for makexp_aix and
ld_so_aix to be found earlier in the process). Here's some output (it's the
same for all modules):

building '_tkinter' extension
/development/utils/lib/python2.1/config/ld_so_aix cc
-bI:/development/utils/lib/python2.1/config/python.exp
build/temp.aix-2-000310094C00-2.1/_tkinter.o
build/temp.aix-2-000310094C00-2.1/tkappinit.o -L/usr/X11/lib
-L/usr/local/lib -ltk8.0 -ltcl8.0 -lld -lX11 -o
build/lib.aix-2-000310094C00-2.1/_tkinter.so
unable to execute /development/utils/lib/python2.1/config/ld_so_aix: No
such file or directory
WARNING: building of extension "_tkinter" failed: command
'/development/utils/lib/python2.1/config/ld_so_aix' failed with exit status
1

There are TWO things I notice here:

1) ld_so_aix is in Modules, not in /development/utils/lib/python2.1/config.
In fact, there is no directory called /development/utils/lib/python2.1.

2) (copied from above)
"/development/utils/lib/python2.1/config/ld_so_aix cc"

Note it says cc, not cc_r, which is how I configured and ran make. cc_r is
darn important, since python will blow up if it's configured with threads
but you don't run cc_r.

Previously this problem was mentioned in bug #129991, which was closed when
I submitted some patches I thought solved the problem...well they were
incomplete. I don't know exactly what to patch for the above problems...


Follow-Ups:

Date: 2001-Feb-16 01:51
By: lemburg

Comment:
Just reading through the checkins today I fonud that Neil has
been fiddling with that code. Perhaps you ought to grab the latest
CVS snapshot and rerun the install ?!
-------------------------------------------------------

Date: 2001-Feb-16 01:45
By: lemburg

Comment:
Ok, here we go again :-)

1)  distutils assumes Python to be already installed on the machine
and thus it looks for the AIX tools in the config dir -- unfortunately,
setup.py is run before these files are installed, so it cannot find
them. Perhaps we ought to add a special case to distutils
which allows finding them anyway ?!

2) It seems as if your make doesn't copy the command line
variables into the OS environment. The setup.py file contains
explicit code which uses the OS environment variables to
choose a compiler and linker:

# When you run "make CC=altcc" or something similar, you really want
# those environment variables passed into the setup.py phase. Here's
# a small set of useful ones.
 compiler = os.environ.get('CC')
 linker_so = os.environ.get('LDSHARED')

Not sure what to do about this. It hints at another problem though:
distutils uses the settings from the Makefile per default. It seems
that in your case it is having trouble parsing that file.

BTW, why does sys.platform return for you ? (There is a switch
in distutils.sysconfig which switches on 'aix4' -- could be that
this causes the problem)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132637&group_id=5470


From noreply@sourceforge.net  Fri Feb 16 10:23:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 02:23:06 -0800
Subject: [Python-bugs-list] [Bug #128973] OpenBSD Problems with _funlockfile in fileobject.c
Message-ID: <E14Ti2c-0006iy-00@usw-sf-web3.sourceforge.net>

Bug #128973, was updated on 2001-Jan-15 21:12
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 3
Submitted by: jpettit
Assigned to : twouters
Summary: OpenBSD Problems with _funlockfile in fileobject.c

Details: When I compile the current CVS version of Python on OpenBSD 2.8, I
get the following linker error:

    ld: _funlockfile: non-function jmpslot
    collect2: ld returned 1 exit status
    *** Error code 1

This function was first added to Python in version 2.97 of "fileobject.c".

Follow-Ups:

Date: 2001-Feb-16 02:23
By: twouters

Comment:
I noticed the test_long as well, and had intended to use the account
provided by ltratt to track it down, but I haven't found the time :(
Closing this bug, though.


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

Date: 2001-Feb-15 11:20
By: jpettit

Comment:
Sorry!  I've been slammed at work.  Yes, it compiles cleanly now. 
Unfortunately, it hangs on "test_long" when I run "make test", but this is
documented in "README" as probably being a compiler error.  If I find
anything else, I'll file a new bug report.  Thanks for your help!
-------------------------------------------------------

Date: 2001-Feb-15 03:33
By: twouters

Comment:
Lowered priority and set resolution to 'works for me' because it does work
for me. Leaving it open for a bit more, to give jpettit a chance to react
and possibly disagree.

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

Date: 2001-Feb-02 07:54
By: twouters

Comment:
Testing the current CVS tree on ltratt's offered OpenBSD machine
(OpenBSD-stable 2.8 on i386) I can't reproduce the problem. I do see these
slightly suspicious messages though:

ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x2d5ec for
"_flockfile"
ld: libpython2.1.a(fileobject.o): RRS text relocation at 0x2d633 for
"_funlockfile"

I suspect this is fixed by an update/patch/whatever OpenBSD uses to one of
the development tools (gcc, ld, libc, whatever OpenBSD uses :)
Unless there was some other difference between the machines of jpettit and
ltratt ?

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

Date: 2001-Feb-02 07:34
By: twouters

Comment:
I've volunteered myself to debug this, on OpenBSD, using the provided
account.



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

Date: 2001-Jan-25 10:38
By: ltratt

Comment:
I'd be happy to offer any of the Python developers an account on an OpenBSD
machine if they wish - mail tratt@dcs.kcl.ac.uk
-------------------------------------------------------

Date: 2001-Jan-18 19:32
By: gvanrossum

Comment:
Alas, it seems that this will remain open in 2.1a1.  Hopefully someone else
will be able to fix it once the alpha1 release is out.

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

Date: 2001-Jan-16 11:58
By: jpettit

Comment:
The man page doesn't seem to specify a particular library to link against. 
It only says to include stdio.h.

I'm building Python without any special flags.  I thought threads were
enabled by default, but just for good measure, I ran configure with
--with-threads and got the same results.

I don't see any reference to flockfile/funlockfile in config.log.
-------------------------------------------------------

Date: 2001-Jan-16 11:00
By: twouters

Comment:
Unfortunately, I don't have access to OpenBSD, just FreeBSD and BSDI.
flockfile/funlockfile both work fine there. I suspect it's a header/library
problem: maybe we need to include a separate header/library, which we for
some reason do in the configure process, but not in the linking of Python
(or maybe it needs additional magic to link together with other libraries,
I don't know.)

jpettit, can you check the manpage for funlockfile to see what headerfiles
should be included, and perhaps what to link with ? Also, are you compiling
threaded or unthreaded ? There is a good chance the flockfile/funlockfile
functions are only available in threaded code, or maybe Python is being
compiled half-threaded for some reason. Checking to see the difference
between what config.log and 'make' say might give some hints, too.

Or it could just be an OS bug :P We should be able to figure it out though:
if Python can't *compile* with those functions, neither should configure.

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

Date: 2001-Jan-16 09:56
By: jpettit

Comment:
I'd be happy to help however I can.  However, autoconf is black magic to
me.  

I think that funlockfile is supposed to be available...there is even a man
page dated 20 August 1998.  This may be another case of OpenBSD improperly
integrating components from the other BSDs.

Please let me know what I can do.
-------------------------------------------------------

Date: 2001-Jan-16 05:28
By: gvanrossum

Comment:
It's gotta be more complicated that that.  The configure script has a test
program that calls flockfile(), getc_unlocked(), and funlockfile().  Only
if this test program links successfully does it decide to use
getc_unlocked().  (Making the test depend on successfully *running* it
shouldn't make a difference -- the user here got a link-time error.)

jpettit, is there a way you could find out why the configure test succeeds
but then you get a link error linking Python?

I'll also ask Thomas Wouters to look into this.

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

Date: 2001-Jan-15 22:19
By: tim_one

Comment:
Ho ho ho:  so this means some flavor of Unix has getc_unlocked() but not
the flockfile() and funlockfile() that are supposed to come with it?  Man,
Windows looks better every day <wink> -- and so does the
getline_via_fgets() hack ...

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=128973&group_id=5470


From noreply@sourceforge.net  Fri Feb 16 10:47:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 02:47:34 -0800
Subject: [Python-bugs-list] [Bug #117464] clash with BSD db when building
Message-ID: <E14TiQI-0004UA-00@usw-sf-web1.sourceforge.net>

Bug #117464, was updated on 2000-Oct-23 00:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: fleury
Assigned to : akuchling
Summary: clash with BSD db when building

Details: On RH7.0, beside the LONG_BIT issue, I came across a db.h
missmatch. 
The preprocessor directive values used in bsddbmodule.c correspond to the
/usr/include/db1/db.h file, but on my system, /usr/include/db.h points to
db3/db.h which does not define the same set of values, and does not
compile.

Compiling with the old file works, but obviously it does not link...

configure (with no options) ran trouble free.

The system is:
RedHat 7.0
gcc version 2.96 20000731 (yes with the LONG_BIT problem) 
Python 2.0 final release

Regards,
Pascal    

Follow-Ups:

Date: 2001-Feb-16 02:47
By: twouters

Comment:
Assigned to Andrew to see if he can rewrite the bsddb detection code in
distutils, like described in bug #132600.


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

Date: 2001-Jan-20 08:51
By: twouters

Comment:
Apologies for not responding sooner, but I'm not sure how to fix this in
autoconf, except for redoing the test entirely, and PEP-229 shows good
promise for fixing this. The answer is pretty complicated anyway. db_185.h
comes with BSDDB 2 and 3, and under RedHat 7, BSDDB 1, 2 and 3 can all be
installed at the same time, in /usr/local/{db1,db2,db3}. 

I think the right fix would be to remove the autoconf stuff, and just check
for the existance of db_185.h in /usr/include/db3 or /usr/include/db2, or
the existance of db.h in /usr/include/db1, and then link with the right
library (which can be libdb-3.1.so, libdb2.so and libdb1.so on my RedHat
system. Confusing, isn't it ? :)

I'll see if I can fix something up, unless someone else does it before
me.

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

Date: 2001-Jan-02 09:13
By: montanaro

Comment:
Reassigned to Thomas Wouters because I think he has RH7.0.
I can't test this directly and haven't had time to investigate.  My
apologies for waiting so long to slough
this off to someone else.


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

Date: 2000-Nov-06 08:40
By: montanaro

Comment:
This is going to require a bit of effort.  My current scheme for detecting
whether bsddb can be built/linked or not relies on the presence or absence
of db.h and/or db_185.h.  If db_185.h is present, libdb v.2 is assumed.  If
only db.h is present, libdb v.1 is assumed.

Now Sleepycat has libdb v.3, and on RH7 it appears you can have all three
versions installed at once.  I don't yet know if bsddbmodule.c can be
built/linked with v.3 (seems likely, since db_185.h still existts), but
even if it can, configure will have to grovel around in db.h looking for
DB_VERSION_MAJOR.  If it doesn't exist, we have v.1.  If it does exist, its
value will determine what version > 1 we have.

I imagine for an autoconf whiz this will be a simple task, but it's more of
a challenge than I have time for at the moment.  Anyone want to take this
on?

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

Date: 2000-Oct-23 18:13
By: fleury

Comment:
Well, I also tried at home, where I have a vanilla RH7.0 and it compiles
perfectly.
The reported bug was on a RH6.2->RH7.0 upgraded machine.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117464&group_id=5470


From noreply@sourceforge.net  Fri Feb 16 10:47:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 02:47:30 -0800
Subject: [Python-bugs-list] [Bug #132600] 2.1a2 tries to build bsddb without "-ldb"
Message-ID: <E14TiQE-0004U7-00@usw-sf-web1.sourceforge.net>

Bug #132600, was updated on 2001-Feb-15 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : akuchling
Summary: 2.1a2 tries to build bsddb without "-ldb"

Details: Platform: Tru64 Unix, V4.0F, Compaq C compiler version: Compaq C
V6.3-129 (dtk) on Digital UNIX V4.0F  (Rev. 1229), Compiler Driver V6.3-126
(dtk)

"make" causes setup.py to generate the following compile/link lines for the
bsddb extension:

cc -O -Olimit 1500 -I.
-I/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include -c
/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/Modules/bsddbmodule.c
-o build/temp.osf1-V4.0-alpha-2.1/bsddbmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V4.0-alpha-2.1/bsddbmodule.o -L/usr/local/lib -o
build/lib.osf1-V4.0-alpha-2.1/bsddb.so

The lack of a "-ldb" in the ld command causes "make test" to skip the bsddb
test (and "import bsddb" to fail) due to unresolved symbols. Looking at the
code in setup.py, the "-ldb" is only included if "db_185.h" is found. If
"db.h" is found instead, no "-l" is appended to the link line. Compaq Tru64
comes standard with db (a Compaq-modified 1.85 version, I believe), with
/usr/include/db.h and /usr/lib/libdb.a and /usr/shlib/libdb.so. Manually
adding "-ldb" to the above link line allows test_bsddb to run and pass.

Follow-Ups:

Date: 2001-Feb-16 02:47
By: twouters

Comment:
This bug is connected to at least one other bsddb bug ("clash with BSD db
when building", #117464) and maybe more. I think the solution is to rip out
all the autoconf stuff and do all the detecting in setup.py. I'm not sure
how to do it, though, and I don't have time to learn distutils right now
:-)

Andrew, assigning this (as well as the other bug) to you, so you can
consider the distutils solution. I can give you a rundown on how it should
work: basically, it should check for /usr/include/db{3,2}/db_185.h,
/usr/include/db1/db.h, /usr/include/db_185.h and /usr/include/db.h in that
order, try to find out if the found db.h is indeed version 1 (if it doesn't
contain a DB_VERSION_MAJOR #define, or it's #defined as 1, it's version 1),
and then try to find out if dbopen() is in libc or not. This all can be
written in autoconf, if it's really necessary, though it would probably
create quite a mess in bsddbmodule.c, what with the
#ifdef/else/ifdef/else/ifdef/else chain to get the right include file.

Let me know if you don't want the job, and I'll do the autoconf way
instead.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132600&group_id=5470


From noreply@sourceforge.net  Fri Feb 16 10:53:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 02:53:07 -0800
Subject: [Python-bugs-list] [Bug #129995] segfaults on AIX if configured with threads
Message-ID: <E14TiVf-0004XF-00@usw-sf-web1.sourceforge.net>

Bug #129995, was updated on 2001-Jan-24 16:44
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Submitted by: bcollar
Assigned to : twouters
Summary: segfaults on AIX if configured with threads

Details: Hi. AIX 4.2.1. ran ./configure --without-gcc
--prefix=/development/utils. make CC=xlC OPT="-O2 -qmaxmem=4000". some of
the make output follows. Let me know if you need all of it.

if test ! -f ../Modules/hassignal;  then echo adding sigcheck.o; ar r
../libpython2.1.a sigcheck.o;  else echo leaving sigcheck.o out; fi
leaving sigcheck.o out
        touch add2lib
        if test -f hassignal;  then echo removing sigcheck.o intrcheck.o; 
ar d ../libpython2.1.a sigcheck.o intrcheck.o 2>/dev/null;  else echo
leaving sigcheck.o intrcheck.o in; fi
removing sigcheck.o intrcheck.o
make: 1254-004 The error code from the last command is 2.
make: 1254-005 Ignored error code 2 from last command.
        ar cr ../libpython2.1.a gcmodule.o  threadmodule.o  posixmodule.o 
_sre.o  signalmodule.o config.o getpath.o main.o getbuildinfo.o
        touch add2lib
        cd Modules; make OPT="-O2 -qmaxmem=4000" python.o
        xlC -O2 -qmaxmem=4000 -I./../Include -I.. -DHAVE_CONFIG_H -c
python.c
        expr `cat buildno` + 1 >buildno1
        mv -f buildno1 buildno
        xlC -c -O2 -qmaxmem=4000 -I. -DHAVE_CONFIG_H -DBUILD=`cat buildno` 
./Modules/getbuildinfo.c
        ar cr libpython2.1.a getbuildinfo.o
        ranlib libpython2.1.a
        true
        cd Modules;  make OPT="-O2 -qmaxmem=4000" VERSION="2.1" 
prefix="/development/utils/" exec_prefix="/development/utils/" 
LIBRARY=../libpython2.1.a link
        ./makexp_aix python.exp "" ../libpython2.1.a;  xlC 
-Wl,-bE:python.exp -lld python.o  ../libpython2.1.a   -ldl  -lpthreads -lm 
-o python 
        mv python ../python
        ./python ./setup.py build
pthread_mutex_init: Error 0
pthread_cond_init: Error 0
pthread_mutex_lock[1]: Error 0
make: 1254-059 The signal code from the last command is 11.


Follow-Ups:

Date: 2001-Feb-16 02:53
By: twouters

Comment:
Marking it 'not a bug', then, to reflect the fact it's something we can't
really fix, and closing it.

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

Date: 2001-Feb-15 15:26
By: bcollar

Comment:
Response to twouters' question: yes, the error is fixed when using cc_r.


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

Date: 2001-Feb-15 03:47
By: twouters

Comment:
I've rewritten the AIX blurb to mention cc_r (or any threadsafe compiler,
really) even when not compiling for C++ support.
bcollar, does using cc_r (or xlC_r) instead of xlC fix your problem ?


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

Date: 2001-Feb-06 09:18
By: donnc

Comment:
Instead of xlC,  use cc_r.  That (on my host anyway) is
the xlC.cfg compiler configuration that uses the reentrant
libraries for thread support, which are not the default.
-------------------------------------------------------

Date: 2001-Feb-02 05:59
By: twouters

Comment:
I'd like to note that though I don't have access to AIX myself, I do live
with and share a bed with a system administrator who does, very much so,
many, many hours per week. She doesn't have a *compiler* on AIX, though, so
more than general AIX info and the odd programmers manual is out of the
question.

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

Date: 2001-Feb-01 09:21
By: bwarsaw

Comment:
Assigning this to Thomas, since I don't have an AIX machine handy, and he
made the mistake of chiming in. :)
-------------------------------------------------------

Date: 2001-Feb-01 06:53
By: twouters

Comment:
Try making sure configure itself is also run with the same CC and OPT
arguments, by running configure like this (using (ba)sh syntax, should work
in ksh as well):

CC=xlC CFLAGS="-O2 -qmaxmem=4000" ./configure <normalopts>

configure might be mis-detecting some things because of the different
arguments.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129995&group_id=5470


From noreply@sourceforge.net  Fri Feb 16 10:55:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 02:55:17 -0800
Subject: [Python-bugs-list] [Bug #132606] 2.1a2 _tkinter build may pick up wrong Tcl/Tk versions
Message-ID: <E14TiXl-0004Yi-00@usw-sf-web1.sourceforge.net>

Bug #132606, was updated on 2001-Feb-15 13:21
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : akuchling
Summary: 2.1a2 _tkinter build may pick up wrong Tcl/Tk versions

Details: Platform: Compaq Tru64 Unix, Version 4.0F, Compaq C V6.3-129 (dtk)
on Digital UNIX V4.0F  (Rev. 1229), Compiler Driver V6.3-126 (dtk) cc
Driver

setup.py generates the following compile and link lines for _tkinter.c:

cc -O -Olimit 1500 -DWITH_APPINIT=1 -I/usr/X11/include -I.
-I/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include -c
/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/Modules/
_tkinter.c -o build/temp.osf1-V4.0-alpha-2.1/_tkinter.o
cc -O -Olimit 1500 -DWITH_APPINIT=1 -I/usr/X11/include -I.
-I/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include -c
/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/Modules/
tkappinit.c -o build/temp.osf1-V4.0-alpha-2.1/tkappinit.o
ld -shared -expect_unresolved * build/temp.osf1-V4.0-alpha-2.1/_tkinter.o
build/
temp.osf1-V4.0-alpha-2.1/tkappinit.o -L/usr/X11/lib -L/usr/local/lib
-ltk8.0 -lt
cl8.0 -lX11 -o build/lib.osf1-V4.0-alpha-2.1/_tkinter.so

/usr/X11/include precedes /usr/local/include and /usr/X11/lib precedes
/usr/local/lib and will be searched first.  /usr/X11/{include,lib} are,
according to the comment in setup.py, the default location for X11. If a
system comes with Tcl/Tk installed, and the user installs a later version
in /usr/local, setup.py will use the earlier version's include files and
(probably) the later versions library files, assuming the version number is
part of the library filename and "-l{tcl,tk}" string. This mismatch will
not be good... This is the case with Tru64, which comes with an old (7.6)
version of Tcl/Tk. The only reason I didn't fall foul of this gotcha was
that Tru64 doesn't have a /usr/X11 directory - it has the standard (but
probably pre-Linux standard!) /usr/include/X11 and /usr/lib/X11 structure.
I'd suggest that for both the includes and libs /usr/local should appear
before the "default" system X11 directories.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132606&group_id=5470


From noreply@sourceforge.net  Fri Feb 16 12:14:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 04:14:15 -0800
Subject: [Python-bugs-list] [Bug #132597] 2.1a2 compiler warnings on Compaq Tru64 Unix
Message-ID: <E14TjmB-0003rJ-00@usw-sf-web2.sourceforge.net>

Bug #132597, was updated on 2001-Feb-15 12:35
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 compiler warnings on Compaq Tru64 Unix

Details: 2.1a2 from CVS of Feb 16 produces the following compiler warnings
on Tru64
Unix (uname -a: OSF1 gonzo.per.dem.csiro.au V4.0 1229 alpha, Compaq C
compiler, version: Compaq C V6.3-129 (dtk), Compiler Driver V6.3-126
(dtk)):

cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Python/ceval.o
Python/ceval.c
cc: Info: Python/ceval.c, line 327: Trailing comma found in enumerator
list. (trailcomma)
};


cc -O -Olimit 1500 -I. -I./Include -IInclude/ -I/usr/local/include -c
Modules/_cursesmodule.c -o build/temp.osf1-V4.0-alpha-2.1/_cursesmodule.o
cc: Warning: Modules/_cursesmodule.c, line 632: In this statement,
"derwin(...)" of type "int", is being converted to "pointer to struct
_win_st". (cvtdiftypes)
  win = derwin(self->win,nlines,ncols,begin_y,begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1287: In this statement,
"subpad(...)" of type "int", is being converted to "pointer to struct
_win_st". (cvtdiftypes)
    win = subpad(self->win, nlines, ncols, begin_y, begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1517: In this statement,
"termname(...)" of type "int", is being converted to "pointer to const
char". (cvtdiftypes)
NoArgReturnStringFunction(termname)

cc: Warning: Modules/_cursesmodule.c, line 1686: In this statement,
"getwin(...)" of type "int", is being converted to "pointer to struct
_win_st". (cvtdiftypes)
  win = getwin(PyFile_AsFile(temp));

cc: Warning: Modules/_cursesmodule.c, line 1954: In this statement,
"keyname(...)" of type "int", is being converted to "pointer to const
char". (cvtdiftypes)
  knp = keyname(ch);

cc: Warning: Modules/_cursesmodule.c, line 2245: In this statement,
"tigetstr(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
        capname = tigetstr( capname );

cc: Warning: Modules/_cursesmodule.c, line 2270: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt);

cc: Warning: Modules/_cursesmodule.c, line 2273: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1);

cc: Warning: Modules/_cursesmodule.c, line 2276: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2);

cc: Warning: Modules/_cursesmodule.c, line 2279: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3);

cc: Warning: Modules/_cursesmodule.c, line 2282: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4);

cc: Warning: Modules/_cursesmodule.c, line 2285: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5);

cc: Warning: Modules/_cursesmodule.c, line 2288: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6);

cc: Warning: Modules/_cursesmodule.c, line 2291: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7);

cc: Warning: Modules/_cursesmodule.c, line 2294: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8);

cc: Warning: Modules/_cursesmodule.c, line 2297: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8,i9);

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg1"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg2"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg1"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg2"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg1"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg2"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")






Follow-Ups:

Date: 2001-Feb-16 04:14
By: twouters

Comment:
The first warning is my mistake. I thought I fixed that in a more recent
version of my continue-inside-try patch, but apparently I didn't. Fixed in
revision 2.230 of Python/ceval.c

The warnings in Modules/_cursusmodule.c are most likely caused by undefined
functions, though why you don't see an error for those beats me. (undefined
functions default to int-returning functions, so that's probably why you
see those warnings.) 

The *other* warnings look damned legit, though, and the only reason they
aren't is because getmaxyx and co. are (on the BSDI and Linux boxes I have
acces to) defined as being macro calls, and in fact they *have* to be macro
calls (or non-standard C calls) or they can't work. I'm not a curses
expert, but I think an initialization is in place here (or just rewriting
the silly macros so they make *sense* :-)

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132597&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 00:42:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 16:42:34 -0800
Subject: [Python-bugs-list] [Bug #132783] 2.1a2 fails to build extensions under Solaris 8 with gcc
Message-ID: <E14TvSM-0000B8-00@usw-sf-web2.sourceforge.net>

Bug #132783, was updated on 2001-Feb-16 16:42
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 fails to build extensions under Solaris 8 with gcc 

Details: Platform: SunOS asafoetida 5.8 Generic_108528-04 sun4u sparc
SUNW,Ultra-60
Compiler: gcc version 2.95.2 19991024 (release)
2.1a2 from CVS of Feb 16

"make" builds the bootstrap python successfully, but fails to build any
extensions due to lack of "-fPIC" compiler option. Putting this option in
by hand allows the extensions to build. A typical error message is:

building 'struct' extension
creating build
creating build/temp.solaris-2.8-sun4u-2.1
gcc -g -O2 -Wall -Wstrict-prototypes -I.
-I/export/home0/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include 
-c /export/home0/mark/src/python/CVS/python/dist/src/Modules/structmodule.c
-o build/temp.solaris-2.8-sun4u-2.1/structmodule.o
creating build/lib.solaris-2.8-sun4u-2.1
gcc -shared build/temp.solaris-2.8-sun4u-2.1/structmodule.o
-L/usr/local/lib -o 
build/lib.solaris-2.8-sun4u-2.1/struct.so
WARNING: building of extension "struct" failed: command 'gcc' failed with
exit status 1

Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x1204     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
<unknown>                           0x1208     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
<unknown>                           0x120c     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
<unknown>                           0x1210     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
.
<lots more elided>
.
PyErr_ExceptionMatches              0xc78      
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
Py_InitModule4                      0x1c48     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
ld: fatal: relocations remain against allocatable but non-writable
sections
collect2: ld returned 1 exit status


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132783&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 00:58:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 16:58:58 -0800
Subject: [Python-bugs-list] [Bug #132786] 2.1a2 "make test" failures under Solaris 8
Message-ID: <E14TviE-0000IC-00@usw-sf-web2.sourceforge.net>

Bug #132786, was updated on 2001-Feb-16 16:58
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 "make test" failures under Solaris 8

Details: 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



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132786&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 01:25:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 17:25:57 -0800
Subject: [Python-bugs-list] [Bug #132787] 2.1a1 compiler warnings under Solaris 8 with gcc
Message-ID: <E14Tw8L-0000TH-00@usw-sf-web2.sourceforge.net>

Bug #132787, was updated on 2001-Feb-16 17:25
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a1 compiler warnings under Solaris 8 with gcc

Details: Platform: SunOS asafoetida 5.8 Generic_108528-04 sun4u sparc
SUNW,Ultra-60
(actually a 220R server)
Compiler: gcc version 2.95.2 19991024 (release)
2.1a2: CVS version of Feb 16

The following compiler warnings are reported:

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Objects/floatobject.o Objects/floatobject.c
Objects/floatobject.c:35: warning: function declaration isn't a prototype

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Objects/intobject.o Objects/intobject.c
Objects/intobject.c: In function `PyInt_FromString':
Objects/intobject.c:185: warning: subscript has type `char'

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Python/errors.o Python/errors.c
Python/errors.c: In function `PyErr_Format':
Python/errors.c:405: warning: subscript has type `char'
Python/errors.c:460: warning: subscript has type `char'
Python/errors.c:465: warning: subscript has type `char'
Python/errors.c:468: warning: subscript has type `char'

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Python/pythonrun.o Python/pythonrun.c
Python/pythonrun.c: In function `initsigs':
Python/pythonrun.c:1192: warning: function declaration isn't a prototype

gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H   
-c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_confstr':
./Modules/posixmodule.c:4524: warning: implicit declaration of function
`confstr'

gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H   
-c ./Modules/signalmodule.c -o Modules/signalmodule.o
./Modules/signalmodule.c:88: warning: function declaration isn't a
prototype
./Modules/signalmodule.c: In function `signal_signal':
./Modules/signalmodule.c:212: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:214: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:225: warning: function declaration isn't a
prototype
./Modules/signalmodule.c: In function `initsignal':
./Modules/signalmodule.c:332: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:336: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:355: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:357: warning: function declaration isn't a
prototype
./Modules/signalmodule.c: In function `finisignal':
./Modules/signalmodule.c:556: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:564: warning: function declaration isn't a
prototype

<gcc compile lines omitted from here down>

Modules/stropmodule.c: In function `strop_atoi':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/stropmodule.c:752:
warning: subscript has type `char'

Modules/timemodule.c: In function `time_strptime':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/timemodule.c:398:
warning: subscript has type `char'

Modules/socketmodule.c: In function `PySocket_socket':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/socketmodule.c:1854:
warning: function declaration isn't a prototype
/export/home0/mark/src/python/CVS/python/dist/src/Modules/socketmodule.c:
In function `PySocket_fromfd':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/socketmodule.c:1892:
warning: function declaration isn't a prototype

In file included from /usr/include/curses.h:23,
from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/curses.h:5,
from Include/py_curses.h:8,
from Modules/_cursesmodule.c:104:
/usr/include/widec.h:38: warning: `getwc' redefined
/usr/include/iso/wchar_iso.h:337: warning: this is the location of the
previous 
definition
/usr/include/widec.h:39: warning: `putwc' redefined
/usr/include/iso/wchar_iso.h:340: warning: this is the location of the
previous 
definition
/usr/include/widec.h:40: warning: `getwchar' redefined
/usr/include/iso/wchar_iso.h:338: warning: this is the location of the
previous 
definition
/usr/include/widec.h:41: warning: `putwchar' redefined
/usr/include/iso/wchar_iso.h:341: warning: this is the location of the
previous 
definition
Modules/_cursesmodule.c: In function `PyCurses_Putp':
Modules/_cursesmodule.c:2135: 
warning: implicit declaration of function `putp'
Modules/_cursesmodule.c: In function `PyCurses_tigetflag':
Modules/_cursesmodule.c:2219: 
warning: implicit declaration of function `tigetflag'
Modules/_cursesmodule.c: In function `PyCurses_tigetnum':
Modules/_cursesmodule.c:2232: 
warning: implicit declaration of function `tigetnum'
Modules/_cursesmodule.c: In function `PyCurses_tigetstr':
Modules/_cursesmodule.c:2245: 
warning: implicit declaration of function `tigetstr'
Modules/_cursesmodule.c:2245: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c: In function `PyCurses_tparm':
Modules/_cursesmodule.c:2270: 
warning: implicit declaration of function `tparm'
Modules/_cursesmodule.c:2270: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2273: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2276: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2279: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2282: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2285: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2288: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2291: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2294: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2297: 
warning: assignment makes pointer from integer without a cast

In file included from /usr/include/curses.h:23,
from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/curses.h:5,
from Include/py_curses.h:8,
from Modules/_curses_panel.c:15:
/usr/include/widec.h:38: warning: `getwc' redefined
/usr/include/iso/wchar_iso.h:337: warning: this is the location of the
previous 
definition
/usr/include/widec.h:39: warning: `putwc' redefined
/usr/include/iso/wchar_iso.h:340: warning: this is the location of the
previous 
definition
/usr/include/widec.h:40: warning: `getwchar' redefined
/usr/include/iso/wchar_iso.h:338: warning: this is the location of the
previous 
definition
/usr/include/widec.h:41: warning: `putwchar' redefined
/usr/include/iso/wchar_iso.h:341: warning: this is the location of the
previous 
definition
Modules/_curses_panel.c: In function `PyCursesPanel_set_panel_userptr':
Modules/_curses_panel.c:307: warning: passing arg 2 of `set_panel_userptr'
from incompatible pointer type

Modules/fpectlmodule.c: In function `fpe_reset':
Modules/fpectlmodule.c:144: warning: implicit declaration of function
`nonstandard_arithmetic'
Modules/fpectlmodule.c:145: warning: implicit declaration of function
`ieee_flags'
Modules/fpectlmodule.c:146: warning: implicit declaration of function
`ieee_handler'




For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132787&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 05:03:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 21:03:40 -0800
Subject: [Python-bugs-list] [Bug #128930] Inconsistent -L, -R options
Message-ID: <E14TzX2-00069I-00@usw-sf-web3.sourceforge.net>

Bug #128930, was updated on 2001-Jan-15 13:35
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: akuchling
Assigned to : akuchling
Summary: Inconsistent -L, -R options

Details: Martin von Loewis observes:

python setup.py build_ext -L/tmp -lbla
 
works now for me. Unfortunately, passing -R is still broken;
 
  python setup.py build_ext -L/tmp -R/tmp -lbla

Also, I wonder what the rationale is for supporting -L/tmp:/var/tmp,
while not supporting the Unixish -L/tmp -L/var/tmp.


Follow-Ups:

Date: 2001-Feb-16 21:03
By: akuchling

Comment:
Revision 1.32 of unixccompiler.py fixes the exception.

Supporting repeated options, on the other hand, is difficult due 
to the design of fancy_getopt.py.  I'm not sure how to rework it, 
and am reluctant to try it so close to beta1.  It's already listed in the
TODO list for Distutils, so we can consider it for 2.2.  In the meantime
I'll mark this bug as closed.


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

Date: 2001-Jan-15 14:59
By: bwarsaw

Comment:
I'm not sure how it's broken for you, but when I try to build the pybsddb3
package passing in a -R flag I get the following exception:

% python setup.py build_ext -R/usr/local/BerkeleyDB.3.1 --inplace
running build_ext
building 'bsddb3._db' extension
skipping src/_db.c (build/temp.linux-i686-2.0/src/_db.o up-to-date)
Traceback (most recent call last):
  File "setup.py", line 122, in ?
    data_files = utils,
  File "/usr/local/lib/python2.0/distutils/core.py", line 138, in setup
    dist.run_commands()
  File "/usr/local/lib/python2.0/distutils/dist.py", line 867, in
run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python2.0/distutils/dist.py", line 887, in
run_command
    cmd_obj.run()
  File "/usr/local/lib/python2.0/distutils/command/build_ext.py", line 225,
in run
    self.build_extensions()
  File "/usr/local/lib/python2.0/distutils/command/build_ext.py", line 441,
in build_extensions
    build_temp=self.build_temp)
  File "/usr/local/lib/python2.0/distutils/ccompiler.py", line 662, in
link_shared_object
    extra_preargs, extra_postargs, build_temp)
  File "/usr/local/lib/python2.0/distutils/unixccompiler.py", line 208, in
link
    (libraries, library_dirs, runtime_library_dirs) = \
  File "/usr/local/lib/python2.0/distutils/ccompiler.py", line 438, in
_fix_lib_args
    runtime_library_dirs = (list (runtime_library_dirs) +
TypeError: can only concatenate list (not "string") to list

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=128930&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 05:16:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 21:16:16 -0800
Subject: [Python-bugs-list] [Bug #129661] library-dirs option in setup.cfg crashes distutils
Message-ID: <E14TzjE-0006Dw-00@usw-sf-web3.sourceforge.net>

Bug #129661, was updated on 2001-Jan-22 02:16
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: larsga
Assigned to : akuchling
Summary: library-dirs option in setup.cfg crashes distutils

Details: When I set 

library-dirs = /usr/src/own/sp-1.3.4/lib

under [build_ext] in my setup.cfg file, I get a traceback from distutils
that looks like this:

[larsga@localhost pysp]$ python setup.py build
running build
running build_ext
building 'pysp' extension
skipping pyspmodule.cxx (build/temp.linux-i686-2.0/pyspmodule.o
up-to-date)
Traceback (most recent call last):
  File "setup.py", line 14, in ?
    license = "BSD-like")
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/core.py",
line 138, in setup
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/dist.py",
line 829, in run_commands
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/dist.py",
line 849, in run_command
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/command/build.py",
line 106, in run
  File "/usr/local/lib/python2.0/cmd.py", line 328, in run_command
    print "\n"
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/dist.py",
line 849, in run_command
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/command/build_ext.py",
line 225, in run
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/command/build_ext.py",
line 441, in build_extensions
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/ccompiler.py",
line 662, in link_shared_object
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/unixccompiler.py",
line 208, in link
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/ccompiler.py",
line 430, in _fix_lib_args
TypeError: can only concatenate list (not "string") to list


If I remove the option, my extension won't build, because gcc can't find
the needed library.

Follow-Ups:

Date: 2001-Feb-16 21:16
By: akuchling

Comment:
I believe this bug was fixed by patch #102971, and therefore isn't 
present in the current CVS tree.  Can you confirm this (perhaps by just
applying the patch) and let me know if that's correct?


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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129661&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 05:35:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 21:35:16 -0800
Subject: [Python-bugs-list] [Bug #129854] old PYTHONPATH confuses setup.py [build|install]
Message-ID: <E14U01c-0006Kb-00@usw-sf-web3.sourceforge.net>

Bug #129854, was updated on 2001-Jan-23 13:18
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: pj99
Assigned to : akuchling
Summary: old PYTHONPATH confuses setup.py [build|install]

Details: Some of the Makefile actions set the value of PYTHONPATH
to the python libraries being built, intentionally over-
riding the ambient value, such as in the Makefile line:

   349:       export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \

But the lines that invoke setup.py:

   163:       ./python$(EXE) $(srcdir)/setup.py build
   431:       ./python$(EXE) $(srcdir)/setup.py install

don't override PYTHONPATH, and when I first tried to
build and install Python 2.1, on a system configured
to be running Python 2.0, these setup lines failed,
with the complaint:

   AttributeError: 'distutils.sysconfig' module has no attribute
'set_python_build'

which is a sensible complaint, given that 2.0 sysconfig
lacks 'set_python_build', 2.1 has it, and setup.py invokes
it.

Would it make sense to be overriding PYTHONPATH for these
lines of the Makefile as well?


Follow-Ups:

Date: 2001-Feb-16 21:35
By: akuchling

Comment:
Good point!  Fixed in revision 1.20 of the top-level Makefile.pre.in, so
this should be correct in 2.1beta1.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129854&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 05:41:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 21:41:42 -0800
Subject: [Python-bugs-list] [Bug #131249] cgi.py opens too many (temporary) files
Message-ID: <E14U07q-0006NB-00@usw-sf-web3.sourceforge.net>

Bug #131249, was updated on 2001-Feb-06 04:59
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: stadt
Assigned to : akuchling
Summary: cgi.py opens too many (temporary) files

Details: cgi.FieldStorage() is used to get the contents of a webform. It
turns out that
for each <input> line, a new temporary file is opened. This causes the
script
that is using cgi.FieldStorage() to reach the webserver's limit of number
of
opened files, as described by 'ulimit -n'. The standard value for Solaris
systems
seems to be 64, so webforms with that many <input> fields cannot be dealt
with.

A solution would seem to use the same temporary filename, since only a
maxmimum one file is (temporarily) used at the same time. I did an "ls|wc
-l"
while the script was running, which showed only zeroes and ones.

(I'm using Python for CyberChair, an online paper submission and reviewing
system.
The webform under discussion has one input field for each reviewer, stating
the
papers he or she is supposed to be reviewing. One conference that is using
CyberChair
has almost 140 reviewers. Their system's open file limit is 64. Using the
same data on
a system with an open file limit of 260 _is_ able to deal with this.)

Follow-Ups:

Date: 2001-Feb-16 21:41
By: akuchling

Comment:
I assume you mean 64 file upload fields, right?  
Can you provide a small test program that triggers the problem?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131249&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 06:04:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 16 Feb 2001 22:04:29 -0800
Subject: [Python-bugs-list] [Bug #131825] doctest.py needs docs
Message-ID: <E14U0Tt-0006VQ-00@usw-sf-web3.sourceforge.net>

Bug #131825, was updated on 2001-Feb-10 01:03
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: tim_one
Assigned to : fdrake
Summary: doctest.py needs docs

Details: I need to write something up for Fred.  The doctest docstrings are
too much info -- need a much quicker intro for the Library Manual, and
point to the docstrings for unusual cases (I personally almost never use
*any* of the fancy stuff!).


Follow-Ups:

Date: 2001-Feb-16 22:04
By: tim_one

Comment:
Moshe did LaTeXification, and I just checked in his patch (which is now
closed).
-------------------------------------------------------

Date: 2001-Feb-14 22:37
By: tim_one

Comment:
Doc, doc!  Who's there?  doctest docs.

https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103808&group_id=5470

Plain ASCII.  See patch comments for other blather.

Assigned to Fred.  But bet he'd like it if someone else with LaTeXification
powers did this.  I'm not mentioning Moshe by name, though.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131825&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 13:47:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 05:47:56 -0800
Subject: [Python-bugs-list] [Bug #132815] getname() already in use by OS
Message-ID: <E14U7iO-0000om-00@usw-sf-web3.sourceforge.net>

Bug #132815, was updated on 2001-Feb-17 05:47
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: zessin_5
Assigned to : nobody
Summary: getname() already in use by OS

Details: There is a name-clash on OpenVMS.

modules/unicodedata.c  defines a function named 'getname'.
This collides with a function that is defined in OpenVMS's
include file '<unixio.h>'.

Here is an extract from the documentation:
]getname
]
]   Returns the file specification associated with a file descriptor.
]
]   Format
]
]   #include   <unixio.h>
]
]   char  getname   (int file_desc , char  buffer, . . . );
 [...]
]   Description
]
]   This function places the file specification in the area
] pointed to by buffer and returns that address.  The area
] pointed to by buffer should be an array large enough to
] contain a fully qualified file specification (the maximum
] length is 256 characters).

Note: 'getname' is also used in include/ucnhash.h

I guess that 'getname' does also exist on other operating
systems, but might just be included by a different header
file. Can this be changed, please?


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132815&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 13:51:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 05:51:01 -0800
Subject: [Python-bugs-list] [Bug #132816] Compiler warning in PYEXPAT.C for extra ';'
Message-ID: <E14U7lN-0000qR-00@usw-sf-web3.sourceforge.net>

Bug #132816, was updated on 2001-Feb-17 05:51
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: zessin_5
Assigned to : nobody
Summary: Compiler warning in PYEXPAT.C for extra ';'

Details: File: modules/pyexpat.c

The DEC C compiler on OpenVMS complains about an extra
semicolon on line 1102:
[...]
static void
init_template_buffer(void)
{
    int i;
    for (i=0;i<256;i++) {
        template_buffer[i]=i;
    };
    template_buffer[256]=0;
};                               <===

int
PyUnknownEncodingHandler(void *encodingHandlerData,
[...]


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132816&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 13:54:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 05:54:15 -0800
Subject: [Python-bugs-list] [Bug #132817] test_ucn fails on OpenVMS - AssertionError
Message-ID: <E14U7oV-0002Ry-00@usw-sf-web1.sourceforge.net>

Bug #132817, was updated on 2001-Feb-17 05:54
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: zessin_5
Assigned to : nobody
Summary: test_ucn fails on OpenVMS - AssertionError

Details: test_ucn

On OpenVMS, this test fails with the following error message:

test test_ucn crashed -- exceptions.AssertionError: failed
 to raise an exception when given a bogus character name


How can I diagnose this?


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132817&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 14:12:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 06:12:47 -0800
Subject: [Python-bugs-list] [Bug #132820] Nested scopes have problems in -O mode
Message-ID: <E14U86R-0004uC-00@usw-sf-web2.sourceforge.net>

Bug #132820, was updated on 2001-Feb-17 06:12
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: lemburg
Assigned to : nobody
Summary: Nested scopes have problems in -O mode

Details: I've just gotten a report by a beta tester of my eGenix
mx-Extensions which sounds like a bug in the compiler.

Here's the URL to the distutils installer which reproduces the
problem when byte-code compiling the file
mx/Tools/mxTools/test.py 

http://www.lemburg.com/python/egenix-mx-base-1.0.0.zip

As it turns out, the compiler error only occurrs when you compile
test.py in optimized mode:

...
byte-compiling
/usr/local/lib/python2.1/site-packages/mx/Tools/mxTools/test.py to
test.pyc
...
byte-compiling
/usr/local/lib/python2.1/site-packages/mx/Tools/mxTools/test.py to
test.pyo
Fatal Python error: unknown scope for a in testkw(2) in
/usr/local/lib/python2.1/site-packages/mx/Tools/mxTools/test.py



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132820&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 14:13:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 06:13:09 -0800
Subject: [Python-bugs-list] [Bug #132820] Nested scopes have problems in -O mode
Message-ID: <E14U86n-0002cv-00@usw-sf-web1.sourceforge.net>

Bug #132820, was updated on 2001-Feb-17 06:12
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: lemburg
Assigned to : jhylton
Summary: Nested scopes have problems in -O mode

Details: I've just gotten a report by a beta tester of my eGenix
mx-Extensions which sounds like a bug in the compiler.

Here's the URL to the distutils installer which reproduces the
problem when byte-code compiling the file
mx/Tools/mxTools/test.py 

http://www.lemburg.com/python/egenix-mx-base-1.0.0.zip

As it turns out, the compiler error only occurrs when you compile
test.py in optimized mode:

...
byte-compiling
/usr/local/lib/python2.1/site-packages/mx/Tools/mxTools/test.py to
test.pyc
...
byte-compiling
/usr/local/lib/python2.1/site-packages/mx/Tools/mxTools/test.py to
test.pyo
Fatal Python error: unknown scope for a in testkw(2) in
/usr/local/lib/python2.1/site-packages/mx/Tools/mxTools/test.py



Follow-Ups:

Date: 2001-Feb-17 06:13
By: lemburg

Comment:
Assigning this to Jeremy, since he knows this code best.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132820&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 14:17:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 06:17:08 -0800
Subject: [Python-bugs-list] [Bug #132820] Nested scopes have problems in -O mode
Message-ID: <E14U8Ae-0002fJ-00@usw-sf-web1.sourceforge.net>

Bug #132820, was updated on 2001-Feb-17 06:12
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: lemburg
Assigned to : jhylton
Summary: Nested scopes have problems in -O mode

Details: I've just gotten a report by a beta tester of my eGenix
mx-Extensions which sounds like a bug in the compiler.

Here's the URL to the distutils installer which reproduces the
problem when byte-code compiling the file
mx/Tools/mxTools/test.py 

http://www.lemburg.com/python/egenix-mx-base-1.0.0.zip

As it turns out, the compiler error only occurrs when you compile
test.py in optimized mode:

...
byte-compiling
/usr/local/lib/python2.1/site-packages/mx/Tools/mxTools/test.py to
test.pyc
...
byte-compiling
/usr/local/lib/python2.1/site-packages/mx/Tools/mxTools/test.py to
test.pyo
Fatal Python error: unknown scope for a in testkw(2) in
/usr/local/lib/python2.1/site-packages/mx/Tools/mxTools/test.py



Follow-Ups:

Date: 2001-Feb-17 06:13
By: lemburg

Comment:
Assigning this to Jeremy, since he knows this code best.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132820&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 18:13:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 10:13:00 -0800
Subject: [Python-bugs-list] [Bug #132816] Compiler warning in PYEXPAT.C for extra ';'
Message-ID: <E14UBqu-0004o9-00@usw-sf-web1.sourceforge.net>

Bug #132816, was updated on 2001-Feb-17 05:51
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: zessin_5
Assigned to : tim_one
Summary: Compiler warning in PYEXPAT.C for extra ';'

Details: File: modules/pyexpat.c

The DEC C compiler on OpenVMS complains about an extra
semicolon on line 1102:
[...]
static void
init_template_buffer(void)
{
    int i;
    for (i=0;i<256;i++) {
        template_buffer[i]=i;
    };
    template_buffer[256]=0;
};                               <===

int
PyUnknownEncodingHandler(void *encodingHandlerData,
[...]


Follow-Ups:

Date: 2001-Feb-17 10:13
By: tim_one

Comment:
Fixed, pyexpat.c rev 2.42.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132816&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 18:20:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 10:20:28 -0800
Subject: [Python-bugs-list] [Bug #132817] test_ucn fails on OpenVMS - AssertionError
Message-ID: <E14UBy8-0004sV-00@usw-sf-web1.sourceforge.net>

Bug #132817, was updated on 2001-Feb-17 05:54
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: zessin_5
Assigned to : effbot
Summary: test_ucn fails on OpenVMS - AssertionError

Details: test_ucn

On OpenVMS, this test fails with the following error message:

test test_ucn crashed -- exceptions.AssertionError: failed
 to raise an exception when given a bogus character name


How can I diagnose this?


Follow-Ups:

Date: 2001-Feb-17 10:20
By: tim_one

Comment:
Assigned to /F.

zessin_5, look at test_ucn.py, if you want.  The error in question is
raised in only one place, verifying that

"\N{blah}"

raises UnicodeError when passed thru unicode-escape.  Don't know why it's
not on your platform.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132817&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 18:45:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 10:45:47 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UCMd-0002vC-00@usw-sf-web3.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: mpmak
Assigned to : nobody
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 19:18:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 11:18:20 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UCs8-00038r-00@usw-sf-web3.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 20:26:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 12:26:06 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UDvi-0003at-00@usw-sf-web3.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-17 12:26
By: tim_one

Comment:
I'm not sure this can be fixed with reasonable effort.

The patch that allowed .pyc files to get executed from the command-line,
and whether or not they have a .pyc/.pyo extension, broke the -x option
(skip first line), by rewinding the file to see whether it begins with the
right magic number.  That undid what -x does (i.e., skip over the first
line).

So I slopped in another hack to restore the file position in case (as is in
fact almost always the case) the .pyc magic-number hack didn't find what it
was looking for.

And there's the rub.  It *turns out* that, using MS's libraries, and
assuming FILE* fp is at the start of the text-mode stream, after

int ch = getc(fp);
long pos = ftell(fp);

then ch is reliably set to the first character in the file.  However, pos
is set to 1 if and only if the first line *ends* with \r\n.  If it ends
with plain \n, pos is left at 0.  This is bizarre and darned hard to
explain, but that is the way it works.

The .pyc hackery later fseek's back to pos and does ungetc(ch).  Since in
your case pos was set to 0, that ends up "stuttering" the first character
(ungetc('p') effectively puts an extra 'p' at the start of the file,
because pos was left at 0).

Since files with Unix line-ends are not proper text-mode files under
Windows, I doubt Microsoft would consider their behavior buggy here, and
neither would the C std (C guarantees very little about how text mode
works).

And I don't see any hope of fixing it short of either:

1. Opening .py files in binary mode and doing line-end translations
ourselves (a good idea, actually, but A Project).

or

2. Redoing the .pyc hack from scratch:  it should be done *before* -x
processing.  But that may require changing Python's C API.

In short, it's a mess.
-------------------------------------------------------

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 20:47:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 12:47:00 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UEFw-0007X4-00@usw-sf-web2.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-17 12:47
By: tim_one

Comment:
Indeed, from stepping thru MS's ftell(), they do a great deal of expensive
fiddling for text-mode streams *assuming* that every \n in the stdio buffer
was originally an \r\n on disk.  When that isn't true, the adjustments they
make yield bizarre results.  We can't do anything about that.
-------------------------------------------------------

Date: 2001-Feb-17 12:26
By: tim_one

Comment:
I'm not sure this can be fixed with reasonable effort.

The patch that allowed .pyc files to get executed from the command-line,
and whether or not they have a .pyc/.pyo extension, broke the -x option
(skip first line), by rewinding the file to see whether it begins with the
right magic number.  That undid what -x does (i.e., skip over the first
line).

So I slopped in another hack to restore the file position in case (as is in
fact almost always the case) the .pyc magic-number hack didn't find what it
was looking for.

And there's the rub.  It *turns out* that, using MS's libraries, and
assuming FILE* fp is at the start of the text-mode stream, after

int ch = getc(fp);
long pos = ftell(fp);

then ch is reliably set to the first character in the file.  However, pos
is set to 1 if and only if the first line *ends* with \r\n.  If it ends
with plain \n, pos is left at 0.  This is bizarre and darned hard to
explain, but that is the way it works.

The .pyc hackery later fseek's back to pos and does ungetc(ch).  Since in
your case pos was set to 0, that ends up "stuttering" the first character
(ungetc('p') effectively puts an extra 'p' at the start of the file,
because pos was left at 0).

Since files with Unix line-ends are not proper text-mode files under
Windows, I doubt Microsoft would consider their behavior buggy here, and
neither would the C std (C guarantees very little about how text mode
works).

And I don't see any hope of fixing it short of either:

1. Opening .py files in binary mode and doing line-end translations
ourselves (a good idea, actually, but A Project).

or

2. Redoing the .pyc hack from scratch:  it should be done *before* -x
processing.  But that may require changing Python's C API.

In short, it's a mess.
-------------------------------------------------------

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 20:56:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 12:56:46 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UEPO-0007bI-00@usw-sf-web2.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-17 12:56
By: zessin_5

Comment:
Additional info:

A change (in pythonrun.c) also broke (partly)
processing on OpenVMS.

The same effect (doubling the first character)
happens when the file is not in stream linefeed
format - otherwise it works as before.
Text editors, however, create files in record
format.

The problem is that the C library on OpenVMS
can only seek on record boundaries - I don't
want to go into too much detail, here.

I've restored the old code from version 2.1a2
in routine 'maybe_pyc_file()' in my copy and
it started working again.
-------------------------------------------------------

Date: 2001-Feb-17 12:47
By: tim_one

Comment:
Indeed, from stepping thru MS's ftell(), they do a great deal of expensive
fiddling for text-mode streams *assuming* that every \n in the stdio buffer
was originally an \r\n on disk.  When that isn't true, the adjustments they
make yield bizarre results.  We can't do anything about that.
-------------------------------------------------------

Date: 2001-Feb-17 12:26
By: tim_one

Comment:
I'm not sure this can be fixed with reasonable effort.

The patch that allowed .pyc files to get executed from the command-line,
and whether or not they have a .pyc/.pyo extension, broke the -x option
(skip first line), by rewinding the file to see whether it begins with the
right magic number.  That undid what -x does (i.e., skip over the first
line).

So I slopped in another hack to restore the file position in case (as is in
fact almost always the case) the .pyc magic-number hack didn't find what it
was looking for.

And there's the rub.  It *turns out* that, using MS's libraries, and
assuming FILE* fp is at the start of the text-mode stream, after

int ch = getc(fp);
long pos = ftell(fp);

then ch is reliably set to the first character in the file.  However, pos
is set to 1 if and only if the first line *ends* with \r\n.  If it ends
with plain \n, pos is left at 0.  This is bizarre and darned hard to
explain, but that is the way it works.

The .pyc hackery later fseek's back to pos and does ungetc(ch).  Since in
your case pos was set to 0, that ends up "stuttering" the first character
(ungetc('p') effectively puts an extra 'p' at the start of the file,
because pos was left at 0).

Since files with Unix line-ends are not proper text-mode files under
Windows, I doubt Microsoft would consider their behavior buggy here, and
neither would the C std (C guarantees very little about how text mode
works).

And I don't see any hope of fixing it short of either:

1. Opening .py files in binary mode and doing line-end translations
ourselves (a good idea, actually, but A Project).

or

2. Redoing the .pyc hack from scratch:  it should be done *before* -x
processing.  But that may require changing Python's C API.

In short, it's a mess.
-------------------------------------------------------

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 21:11:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 13:11:27 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UEdb-0003t6-00@usw-sf-web3.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-17 13:11
By: mpmak

Comment:

Brute force hack helps - at last for MS:

#ifdef _MSC_VER
		const long currentpos = ftell(fp);
		int ispyc = fread(buf, 1, 2, fp) == 2 &&
		        ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
		fseek(fp, currentpos, SEEK_SET);
#else
... current CVS code goes here
#endif

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

Date: 2001-Feb-17 12:56
By: zessin_5

Comment:
Additional info:

A change (in pythonrun.c) also broke (partly)
processing on OpenVMS.

The same effect (doubling the first character)
happens when the file is not in stream linefeed
format - otherwise it works as before.
Text editors, however, create files in record
format.

The problem is that the C library on OpenVMS
can only seek on record boundaries - I don't
want to go into too much detail, here.

I've restored the old code from version 2.1a2
in routine 'maybe_pyc_file()' in my copy and
it started working again.
-------------------------------------------------------

Date: 2001-Feb-17 12:47
By: tim_one

Comment:
Indeed, from stepping thru MS's ftell(), they do a great deal of expensive
fiddling for text-mode streams *assuming* that every \n in the stdio buffer
was originally an \r\n on disk.  When that isn't true, the adjustments they
make yield bizarre results.  We can't do anything about that.
-------------------------------------------------------

Date: 2001-Feb-17 12:26
By: tim_one

Comment:
I'm not sure this can be fixed with reasonable effort.

The patch that allowed .pyc files to get executed from the command-line,
and whether or not they have a .pyc/.pyo extension, broke the -x option
(skip first line), by rewinding the file to see whether it begins with the
right magic number.  That undid what -x does (i.e., skip over the first
line).

So I slopped in another hack to restore the file position in case (as is in
fact almost always the case) the .pyc magic-number hack didn't find what it
was looking for.

And there's the rub.  It *turns out* that, using MS's libraries, and
assuming FILE* fp is at the start of the text-mode stream, after

int ch = getc(fp);
long pos = ftell(fp);

then ch is reliably set to the first character in the file.  However, pos
is set to 1 if and only if the first line *ends* with \r\n.  If it ends
with plain \n, pos is left at 0.  This is bizarre and darned hard to
explain, but that is the way it works.

The .pyc hackery later fseek's back to pos and does ungetc(ch).  Since in
your case pos was set to 0, that ends up "stuttering" the first character
(ungetc('p') effectively puts an extra 'p' at the start of the file,
because pos was left at 0).

Since files with Unix line-ends are not proper text-mode files under
Windows, I doubt Microsoft would consider their behavior buggy here, and
neither would the C std (C guarantees very little about how text mode
works).

And I don't see any hope of fixing it short of either:

1. Opening .py files in binary mode and doing line-end translations
ourselves (a good idea, actually, but A Project).

or

2. Redoing the .pyc hack from scratch:  it should be done *before* -x
processing.  But that may require changing Python's C API.

In short, it's a mess.
-------------------------------------------------------

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 21:27:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 13:27:19 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UEsx-0007nk-00@usw-sf-web2.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-17 13:27
By: tim_one

Comment:
Sorry, can't figure out what you think that code accomplishes.  Did you try
an example using -x?  Windows is the primary reason -x exists, so no hack
that leaves -x broken on Windows is acceptable.  The getc/ungetc business
is needed so that in *case* -x was specified (and without a change to the C
API, we have no way to know whether it was at this point), the \n that -x
ungetc'ed gets pushed back.  Else line numbers in tracebacks are off by one
under -x, and that's not acceptable either.
-------------------------------------------------------

Date: 2001-Feb-17 13:11
By: mpmak

Comment:

Brute force hack helps - at last for MS:

#ifdef _MSC_VER
		const long currentpos = ftell(fp);
		int ispyc = fread(buf, 1, 2, fp) == 2 &&
		        ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
		fseek(fp, currentpos, SEEK_SET);
#else
... current CVS code goes here
#endif

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

Date: 2001-Feb-17 12:56
By: zessin_5

Comment:
Additional info:

A change (in pythonrun.c) also broke (partly)
processing on OpenVMS.

The same effect (doubling the first character)
happens when the file is not in stream linefeed
format - otherwise it works as before.
Text editors, however, create files in record
format.

The problem is that the C library on OpenVMS
can only seek on record boundaries - I don't
want to go into too much detail, here.

I've restored the old code from version 2.1a2
in routine 'maybe_pyc_file()' in my copy and
it started working again.
-------------------------------------------------------

Date: 2001-Feb-17 12:47
By: tim_one

Comment:
Indeed, from stepping thru MS's ftell(), they do a great deal of expensive
fiddling for text-mode streams *assuming* that every \n in the stdio buffer
was originally an \r\n on disk.  When that isn't true, the adjustments they
make yield bizarre results.  We can't do anything about that.
-------------------------------------------------------

Date: 2001-Feb-17 12:26
By: tim_one

Comment:
I'm not sure this can be fixed with reasonable effort.

The patch that allowed .pyc files to get executed from the command-line,
and whether or not they have a .pyc/.pyo extension, broke the -x option
(skip first line), by rewinding the file to see whether it begins with the
right magic number.  That undid what -x does (i.e., skip over the first
line).

So I slopped in another hack to restore the file position in case (as is in
fact almost always the case) the .pyc magic-number hack didn't find what it
was looking for.

And there's the rub.  It *turns out* that, using MS's libraries, and
assuming FILE* fp is at the start of the text-mode stream, after

int ch = getc(fp);
long pos = ftell(fp);

then ch is reliably set to the first character in the file.  However, pos
is set to 1 if and only if the first line *ends* with \r\n.  If it ends
with plain \n, pos is left at 0.  This is bizarre and darned hard to
explain, but that is the way it works.

The .pyc hackery later fseek's back to pos and does ungetc(ch).  Since in
your case pos was set to 0, that ends up "stuttering" the first character
(ungetc('p') effectively puts an extra 'p' at the start of the file,
because pos was left at 0).

Since files with Unix line-ends are not proper text-mode files under
Windows, I doubt Microsoft would consider their behavior buggy here, and
neither would the C std (C guarantees very little about how text mode
works).

And I don't see any hope of fixing it short of either:

1. Opening .py files in binary mode and doing line-end translations
ourselves (a good idea, actually, but A Project).

or

2. Redoing the .pyc hack from scratch:  it should be done *before* -x
processing.  But that may require changing Python's C API.

In short, it's a mess.
-------------------------------------------------------

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 21:31:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 13:31:59 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UExT-0007pY-00@usw-sf-web2.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-17 13:31
By: tim_one

Comment:
zessin_5, then you must have rebroken -x under OpenVMS.  Yes?

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

Date: 2001-Feb-17 13:27
By: tim_one

Comment:
Sorry, can't figure out what you think that code accomplishes.  Did you try
an example using -x?  Windows is the primary reason -x exists, so no hack
that leaves -x broken on Windows is acceptable.  The getc/ungetc business
is needed so that in *case* -x was specified (and without a change to the C
API, we have no way to know whether it was at this point), the \n that -x
ungetc'ed gets pushed back.  Else line numbers in tracebacks are off by one
under -x, and that's not acceptable either.
-------------------------------------------------------

Date: 2001-Feb-17 13:11
By: mpmak

Comment:

Brute force hack helps - at last for MS:

#ifdef _MSC_VER
		const long currentpos = ftell(fp);
		int ispyc = fread(buf, 1, 2, fp) == 2 &&
		        ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
		fseek(fp, currentpos, SEEK_SET);
#else
... current CVS code goes here
#endif

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

Date: 2001-Feb-17 12:56
By: zessin_5

Comment:
Additional info:

A change (in pythonrun.c) also broke (partly)
processing on OpenVMS.

The same effect (doubling the first character)
happens when the file is not in stream linefeed
format - otherwise it works as before.
Text editors, however, create files in record
format.

The problem is that the C library on OpenVMS
can only seek on record boundaries - I don't
want to go into too much detail, here.

I've restored the old code from version 2.1a2
in routine 'maybe_pyc_file()' in my copy and
it started working again.
-------------------------------------------------------

Date: 2001-Feb-17 12:47
By: tim_one

Comment:
Indeed, from stepping thru MS's ftell(), they do a great deal of expensive
fiddling for text-mode streams *assuming* that every \n in the stdio buffer
was originally an \r\n on disk.  When that isn't true, the adjustments they
make yield bizarre results.  We can't do anything about that.
-------------------------------------------------------

Date: 2001-Feb-17 12:26
By: tim_one

Comment:
I'm not sure this can be fixed with reasonable effort.

The patch that allowed .pyc files to get executed from the command-line,
and whether or not they have a .pyc/.pyo extension, broke the -x option
(skip first line), by rewinding the file to see whether it begins with the
right magic number.  That undid what -x does (i.e., skip over the first
line).

So I slopped in another hack to restore the file position in case (as is in
fact almost always the case) the .pyc magic-number hack didn't find what it
was looking for.

And there's the rub.  It *turns out* that, using MS's libraries, and
assuming FILE* fp is at the start of the text-mode stream, after

int ch = getc(fp);
long pos = ftell(fp);

then ch is reliably set to the first character in the file.  However, pos
is set to 1 if and only if the first line *ends* with \r\n.  If it ends
with plain \n, pos is left at 0.  This is bizarre and darned hard to
explain, but that is the way it works.

The .pyc hackery later fseek's back to pos and does ungetc(ch).  Since in
your case pos was set to 0, that ends up "stuttering" the first character
(ungetc('p') effectively puts an extra 'p' at the start of the file,
because pos was left at 0).

Since files with Unix line-ends are not proper text-mode files under
Windows, I doubt Microsoft would consider their behavior buggy here, and
neither would the C std (C guarantees very little about how text mode
works).

And I don't see any hope of fixing it short of either:

1. Opening .py files in binary mode and doing line-end translations
ourselves (a good idea, actually, but A Project).

or

2. Redoing the .pyc hack from scratch:  it should be done *before* -x
processing.  But that may require changing Python's C API.

In short, it's a mess.
-------------------------------------------------------

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 21:45:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 13:45:43 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UFAl-0007vD-00@usw-sf-web2.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-17 13:45
By: mpmak

Comment:

I have tested it on Windows NT 4.0,MSVC 6.0 SP4, with python from cvs
and:

-x - works as expected inside cmd files
*.py - are compiled/executed properly
*.pyc - python can execute pyc files too

linen umbers in buggy cmd/py files are shown corectly, in any case this
script fails when executing line 3:

#@python -x "%~f0" %* & goto :EOF
print 'ok'
makeanerror

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

Date: 2001-Feb-17 13:31
By: tim_one

Comment:
zessin_5, then you must have rebroken -x under OpenVMS.  Yes?

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

Date: 2001-Feb-17 13:27
By: tim_one

Comment:
Sorry, can't figure out what you think that code accomplishes.  Did you try
an example using -x?  Windows is the primary reason -x exists, so no hack
that leaves -x broken on Windows is acceptable.  The getc/ungetc business
is needed so that in *case* -x was specified (and without a change to the C
API, we have no way to know whether it was at this point), the \n that -x
ungetc'ed gets pushed back.  Else line numbers in tracebacks are off by one
under -x, and that's not acceptable either.
-------------------------------------------------------

Date: 2001-Feb-17 13:11
By: mpmak

Comment:

Brute force hack helps - at last for MS:

#ifdef _MSC_VER
		const long currentpos = ftell(fp);
		int ispyc = fread(buf, 1, 2, fp) == 2 &&
		        ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
		fseek(fp, currentpos, SEEK_SET);
#else
... current CVS code goes here
#endif

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

Date: 2001-Feb-17 12:56
By: zessin_5

Comment:
Additional info:

A change (in pythonrun.c) also broke (partly)
processing on OpenVMS.

The same effect (doubling the first character)
happens when the file is not in stream linefeed
format - otherwise it works as before.
Text editors, however, create files in record
format.

The problem is that the C library on OpenVMS
can only seek on record boundaries - I don't
want to go into too much detail, here.

I've restored the old code from version 2.1a2
in routine 'maybe_pyc_file()' in my copy and
it started working again.
-------------------------------------------------------

Date: 2001-Feb-17 12:47
By: tim_one

Comment:
Indeed, from stepping thru MS's ftell(), they do a great deal of expensive
fiddling for text-mode streams *assuming* that every \n in the stdio buffer
was originally an \r\n on disk.  When that isn't true, the adjustments they
make yield bizarre results.  We can't do anything about that.
-------------------------------------------------------

Date: 2001-Feb-17 12:26
By: tim_one

Comment:
I'm not sure this can be fixed with reasonable effort.

The patch that allowed .pyc files to get executed from the command-line,
and whether or not they have a .pyc/.pyo extension, broke the -x option
(skip first line), by rewinding the file to see whether it begins with the
right magic number.  That undid what -x does (i.e., skip over the first
line).

So I slopped in another hack to restore the file position in case (as is in
fact almost always the case) the .pyc magic-number hack didn't find what it
was looking for.

And there's the rub.  It *turns out* that, using MS's libraries, and
assuming FILE* fp is at the start of the text-mode stream, after

int ch = getc(fp);
long pos = ftell(fp);

then ch is reliably set to the first character in the file.  However, pos
is set to 1 if and only if the first line *ends* with \r\n.  If it ends
with plain \n, pos is left at 0.  This is bizarre and darned hard to
explain, but that is the way it works.

The .pyc hackery later fseek's back to pos and does ungetc(ch).  Since in
your case pos was set to 0, that ends up "stuttering" the first character
(ungetc('p') effectively puts an extra 'p' at the start of the file,
because pos was left at 0).

Since files with Unix line-ends are not proper text-mode files under
Windows, I doubt Microsoft would consider their behavior buggy here, and
neither would the C std (C guarantees very little about how text mode
works).

And I don't see any hope of fixing it short of either:

1. Opening .py files in binary mode and doing line-end translations
ourselves (a good idea, actually, but A Project).

or

2. Redoing the .pyc hack from scratch:  it should be done *before* -x
processing.  But that may require changing Python's C API.

In short, it's a mess.
-------------------------------------------------------

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 22:09:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 14:09:07 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UFXP-0004H6-00@usw-sf-web3.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-17 14:09
By: tim_one

Comment:
Please try pythonrun.c rev 2.123.

Since fseek is a platform-dependent accident in text mode, I don't want to
use that at all anymore.

zessin_5, how does rev 2.123 work for you under OpenVMS?  I won't close
this bug for a few days pending your answer.
-------------------------------------------------------

Date: 2001-Feb-17 13:45
By: mpmak

Comment:

I have tested it on Windows NT 4.0,MSVC 6.0 SP4, with python from cvs
and:

-x - works as expected inside cmd files
*.py - are compiled/executed properly
*.pyc - python can execute pyc files too

linen umbers in buggy cmd/py files are shown corectly, in any case this
script fails when executing line 3:

#@python -x "%~f0" %* & goto :EOF
print 'ok'
makeanerror

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

Date: 2001-Feb-17 13:31
By: tim_one

Comment:
zessin_5, then you must have rebroken -x under OpenVMS.  Yes?

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

Date: 2001-Feb-17 13:27
By: tim_one

Comment:
Sorry, can't figure out what you think that code accomplishes.  Did you try
an example using -x?  Windows is the primary reason -x exists, so no hack
that leaves -x broken on Windows is acceptable.  The getc/ungetc business
is needed so that in *case* -x was specified (and without a change to the C
API, we have no way to know whether it was at this point), the \n that -x
ungetc'ed gets pushed back.  Else line numbers in tracebacks are off by one
under -x, and that's not acceptable either.
-------------------------------------------------------

Date: 2001-Feb-17 13:11
By: mpmak

Comment:

Brute force hack helps - at last for MS:

#ifdef _MSC_VER
		const long currentpos = ftell(fp);
		int ispyc = fread(buf, 1, 2, fp) == 2 &&
		        ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
		fseek(fp, currentpos, SEEK_SET);
#else
... current CVS code goes here
#endif

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

Date: 2001-Feb-17 12:56
By: zessin_5

Comment:
Additional info:

A change (in pythonrun.c) also broke (partly)
processing on OpenVMS.

The same effect (doubling the first character)
happens when the file is not in stream linefeed
format - otherwise it works as before.
Text editors, however, create files in record
format.

The problem is that the C library on OpenVMS
can only seek on record boundaries - I don't
want to go into too much detail, here.

I've restored the old code from version 2.1a2
in routine 'maybe_pyc_file()' in my copy and
it started working again.
-------------------------------------------------------

Date: 2001-Feb-17 12:47
By: tim_one

Comment:
Indeed, from stepping thru MS's ftell(), they do a great deal of expensive
fiddling for text-mode streams *assuming* that every \n in the stdio buffer
was originally an \r\n on disk.  When that isn't true, the adjustments they
make yield bizarre results.  We can't do anything about that.
-------------------------------------------------------

Date: 2001-Feb-17 12:26
By: tim_one

Comment:
I'm not sure this can be fixed with reasonable effort.

The patch that allowed .pyc files to get executed from the command-line,
and whether or not they have a .pyc/.pyo extension, broke the -x option
(skip first line), by rewinding the file to see whether it begins with the
right magic number.  That undid what -x does (i.e., skip over the first
line).

So I slopped in another hack to restore the file position in case (as is in
fact almost always the case) the .pyc magic-number hack didn't find what it
was looking for.

And there's the rub.  It *turns out* that, using MS's libraries, and
assuming FILE* fp is at the start of the text-mode stream, after

int ch = getc(fp);
long pos = ftell(fp);

then ch is reliably set to the first character in the file.  However, pos
is set to 1 if and only if the first line *ends* with \r\n.  If it ends
with plain \n, pos is left at 0.  This is bizarre and darned hard to
explain, but that is the way it works.

The .pyc hackery later fseek's back to pos and does ungetc(ch).  Since in
your case pos was set to 0, that ends up "stuttering" the first character
(ungetc('p') effectively puts an extra 'p' at the start of the file,
because pos was left at 0).

Since files with Unix line-ends are not proper text-mode files under
Windows, I doubt Microsoft would consider their behavior buggy here, and
neither would the C std (C guarantees very little about how text mode
works).

And I don't see any hope of fixing it short of either:

1. Opening .py files in binary mode and doing line-end translations
ourselves (a good idea, actually, but A Project).

or

2. Redoing the .pyc hack from scratch:  it should be done *before* -x
processing.  But that may require changing Python's C API.

In short, it's a mess.
-------------------------------------------------------

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 22:37:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 14:37:40 -0800
Subject: [Python-bugs-list] [Bug #132817] test_ucn fails on OpenVMS - AssertionError
Message-ID: <E14UFz2-0004Ss-00@usw-sf-web3.sourceforge.net>

Bug #132817, was updated on 2001-Feb-17 05:54
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: zessin_5
Assigned to : effbot
Summary: test_ucn fails on OpenVMS - AssertionError

Details: test_ucn

On OpenVMS, this test fails with the following error message:

test test_ucn crashed -- exceptions.AssertionError: failed
 to raise an exception when given a bogus character name


How can I diagnose this?


Follow-Ups:

Date: 2001-Feb-17 14:37
By: zessin_5

Comment:
Here is the result from my debugging:

UNICODEOBJECT.C
if (!ucnhash_CAPI->getcode(start, endBrace-start, &chr)) {

calls:
UNICODEDATA.C:
getcode(const char* name, int namelen, Py_UCS4* code)
{

There are 4 'return's in getcode().
After I replace the 'return -1;' with 'return 0;'
I get the exceptions.
-------------------------------------------------------

Date: 2001-Feb-17 10:20
By: tim_one

Comment:
Assigned to /F.

zessin_5, look at test_ucn.py, if you want.  The error in question is
raised in only one place, verifying that

"\N{blah}"

raises UnicodeError when passed thru unicode-escape.  Don't know why it's
not on your platform.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132817&group_id=5470


From noreply@sourceforge.net  Sat Feb 17 22:39:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 14:39:15 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UG0Z-0004TN-00@usw-sf-web3.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-17 14:39
By: mpmak

Comment:

Inside NT works.
Thanks.

PS same effect without fseek/ftell:

int ispyc = 0;
int bytesread=fread(buf, 1, 2, fp);
ispyc = bytesread == 2 &&
  ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
while( !ispyc && bytesread>0 ){
 ungetc(buf[--bytesread], fp);
}

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

Date: 2001-Feb-17 14:09
By: tim_one

Comment:
Please try pythonrun.c rev 2.123.

Since fseek is a platform-dependent accident in text mode, I don't want to
use that at all anymore.

zessin_5, how does rev 2.123 work for you under OpenVMS?  I won't close
this bug for a few days pending your answer.
-------------------------------------------------------

Date: 2001-Feb-17 13:45
By: mpmak

Comment:

I have tested it on Windows NT 4.0,MSVC 6.0 SP4, with python from cvs
and:

-x - works as expected inside cmd files
*.py - are compiled/executed properly
*.pyc - python can execute pyc files too

linen umbers in buggy cmd/py files are shown corectly, in any case this
script fails when executing line 3:

#@python -x "%~f0" %* & goto :EOF
print 'ok'
makeanerror

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

Date: 2001-Feb-17 13:31
By: tim_one

Comment:
zessin_5, then you must have rebroken -x under OpenVMS.  Yes?

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

Date: 2001-Feb-17 13:27
By: tim_one

Comment:
Sorry, can't figure out what you think that code accomplishes.  Did you try
an example using -x?  Windows is the primary reason -x exists, so no hack
that leaves -x broken on Windows is acceptable.  The getc/ungetc business
is needed so that in *case* -x was specified (and without a change to the C
API, we have no way to know whether it was at this point), the \n that -x
ungetc'ed gets pushed back.  Else line numbers in tracebacks are off by one
under -x, and that's not acceptable either.
-------------------------------------------------------

Date: 2001-Feb-17 13:11
By: mpmak

Comment:

Brute force hack helps - at last for MS:

#ifdef _MSC_VER
		const long currentpos = ftell(fp);
		int ispyc = fread(buf, 1, 2, fp) == 2 &&
		        ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
		fseek(fp, currentpos, SEEK_SET);
#else
... current CVS code goes here
#endif

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

Date: 2001-Feb-17 12:56
By: zessin_5

Comment:
Additional info:

A change (in pythonrun.c) also broke (partly)
processing on OpenVMS.

The same effect (doubling the first character)
happens when the file is not in stream linefeed
format - otherwise it works as before.
Text editors, however, create files in record
format.

The problem is that the C library on OpenVMS
can only seek on record boundaries - I don't
want to go into too much detail, here.

I've restored the old code from version 2.1a2
in routine 'maybe_pyc_file()' in my copy and
it started working again.
-------------------------------------------------------

Date: 2001-Feb-17 12:47
By: tim_one

Comment:
Indeed, from stepping thru MS's ftell(), they do a great deal of expensive
fiddling for text-mode streams *assuming* that every \n in the stdio buffer
was originally an \r\n on disk.  When that isn't true, the adjustments they
make yield bizarre results.  We can't do anything about that.
-------------------------------------------------------

Date: 2001-Feb-17 12:26
By: tim_one

Comment:
I'm not sure this can be fixed with reasonable effort.

The patch that allowed .pyc files to get executed from the command-line,
and whether or not they have a .pyc/.pyo extension, broke the -x option
(skip first line), by rewinding the file to see whether it begins with the
right magic number.  That undid what -x does (i.e., skip over the first
line).

So I slopped in another hack to restore the file position in case (as is in
fact almost always the case) the .pyc magic-number hack didn't find what it
was looking for.

And there's the rub.  It *turns out* that, using MS's libraries, and
assuming FILE* fp is at the start of the text-mode stream, after

int ch = getc(fp);
long pos = ftell(fp);

then ch is reliably set to the first character in the file.  However, pos
is set to 1 if and only if the first line *ends* with \r\n.  If it ends
with plain \n, pos is left at 0.  This is bizarre and darned hard to
explain, but that is the way it works.

The .pyc hackery later fseek's back to pos and does ungetc(ch).  Since in
your case pos was set to 0, that ends up "stuttering" the first character
(ungetc('p') effectively puts an extra 'p' at the start of the file,
because pos was left at 0).

Since files with Unix line-ends are not proper text-mode files under
Windows, I doubt Microsoft would consider their behavior buggy here, and
neither would the C std (C guarantees very little about how text mode
works).

And I don't see any hope of fixing it short of either:

1. Opening .py files in binary mode and doing line-end translations
ourselves (a good idea, actually, but A Project).

or

2. Redoing the .pyc hack from scratch:  it should be done *before* -x
processing.  But that may require changing Python's C API.

In short, it's a mess.
-------------------------------------------------------

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 00:17:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 16:17:49 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UHXx-000888-00@usw-sf-web1.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-17 16:17
By: tim_one

Comment:
Thought about that, but it won't fly:  the C std (whether C89 or C99)
guarantees only one character of pushback via ungetc; the typical case here
would have 2, and whether or not that works is again a platform-dependent
accident.
-------------------------------------------------------

Date: 2001-Feb-17 14:39
By: mpmak

Comment:

Inside NT works.
Thanks.

PS same effect without fseek/ftell:

int ispyc = 0;
int bytesread=fread(buf, 1, 2, fp);
ispyc = bytesread == 2 &&
  ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
while( !ispyc && bytesread>0 ){
 ungetc(buf[--bytesread], fp);
}

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

Date: 2001-Feb-17 14:09
By: tim_one

Comment:
Please try pythonrun.c rev 2.123.

Since fseek is a platform-dependent accident in text mode, I don't want to
use that at all anymore.

zessin_5, how does rev 2.123 work for you under OpenVMS?  I won't close
this bug for a few days pending your answer.
-------------------------------------------------------

Date: 2001-Feb-17 13:45
By: mpmak

Comment:

I have tested it on Windows NT 4.0,MSVC 6.0 SP4, with python from cvs
and:

-x - works as expected inside cmd files
*.py - are compiled/executed properly
*.pyc - python can execute pyc files too

linen umbers in buggy cmd/py files are shown corectly, in any case this
script fails when executing line 3:

#@python -x "%~f0" %* & goto :EOF
print 'ok'
makeanerror

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

Date: 2001-Feb-17 13:31
By: tim_one

Comment:
zessin_5, then you must have rebroken -x under OpenVMS.  Yes?

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

Date: 2001-Feb-17 13:27
By: tim_one

Comment:
Sorry, can't figure out what you think that code accomplishes.  Did you try
an example using -x?  Windows is the primary reason -x exists, so no hack
that leaves -x broken on Windows is acceptable.  The getc/ungetc business
is needed so that in *case* -x was specified (and without a change to the C
API, we have no way to know whether it was at this point), the \n that -x
ungetc'ed gets pushed back.  Else line numbers in tracebacks are off by one
under -x, and that's not acceptable either.
-------------------------------------------------------

Date: 2001-Feb-17 13:11
By: mpmak

Comment:

Brute force hack helps - at last for MS:

#ifdef _MSC_VER
		const long currentpos = ftell(fp);
		int ispyc = fread(buf, 1, 2, fp) == 2 &&
		        ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
		fseek(fp, currentpos, SEEK_SET);
#else
... current CVS code goes here
#endif

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

Date: 2001-Feb-17 12:56
By: zessin_5

Comment:
Additional info:

A change (in pythonrun.c) also broke (partly)
processing on OpenVMS.

The same effect (doubling the first character)
happens when the file is not in stream linefeed
format - otherwise it works as before.
Text editors, however, create files in record
format.

The problem is that the C library on OpenVMS
can only seek on record boundaries - I don't
want to go into too much detail, here.

I've restored the old code from version 2.1a2
in routine 'maybe_pyc_file()' in my copy and
it started working again.
-------------------------------------------------------

Date: 2001-Feb-17 12:47
By: tim_one

Comment:
Indeed, from stepping thru MS's ftell(), they do a great deal of expensive
fiddling for text-mode streams *assuming* that every \n in the stdio buffer
was originally an \r\n on disk.  When that isn't true, the adjustments they
make yield bizarre results.  We can't do anything about that.
-------------------------------------------------------

Date: 2001-Feb-17 12:26
By: tim_one

Comment:
I'm not sure this can be fixed with reasonable effort.

The patch that allowed .pyc files to get executed from the command-line,
and whether or not they have a .pyc/.pyo extension, broke the -x option
(skip first line), by rewinding the file to see whether it begins with the
right magic number.  That undid what -x does (i.e., skip over the first
line).

So I slopped in another hack to restore the file position in case (as is in
fact almost always the case) the .pyc magic-number hack didn't find what it
was looking for.

And there's the rub.  It *turns out* that, using MS's libraries, and
assuming FILE* fp is at the start of the text-mode stream, after

int ch = getc(fp);
long pos = ftell(fp);

then ch is reliably set to the first character in the file.  However, pos
is set to 1 if and only if the first line *ends* with \r\n.  If it ends
with plain \n, pos is left at 0.  This is bizarre and darned hard to
explain, but that is the way it works.

The .pyc hackery later fseek's back to pos and does ungetc(ch).  Since in
your case pos was set to 0, that ends up "stuttering" the first character
(ungetc('p') effectively puts an extra 'p' at the start of the file,
because pos was left at 0).

Since files with Unix line-ends are not proper text-mode files under
Windows, I doubt Microsoft would consider their behavior buggy here, and
neither would the C std (C guarantees very little about how text mode
works).

And I don't see any hope of fixing it short of either:

1. Opening .py files in binary mode and doing line-end translations
ourselves (a good idea, actually, but A Project).

or

2. Redoing the .pyc hack from scratch:  it should be done *before* -x
processing.  But that may require changing Python's C API.

In short, it's a mess.
-------------------------------------------------------

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 00:29:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 16:29:12 -0800
Subject: [Python-bugs-list] [Bug #132879] 2.1a2 minor bug in "make clean" target
Message-ID: <E14UHiy-0005BD-00@usw-sf-web3.sourceforge.net>

Bug #132879, was updated on 2001-Feb-17 16:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 minor bug in "make clean" target

Details: 2..1a2 from CVS of Feb 18 has the following as part of the "make
clean" target:
if test -f build; then find build -name '*.o' -exec rm -f {} ';' ; fi
"build" is a directory, so test should be "test -d build". I'll submit a
patch for this.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132879&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 00:56:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 16:56:02 -0800
Subject: [Python-bugs-list] [Bug #132783] 2.1a2 fails to build extensions under Solaris 8 with gcc
Message-ID: <E14UI8w-00005l-00@usw-sf-web1.sourceforge.net>

Bug #132783, was updated on 2001-Feb-16 16:42
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 fails to build extensions under Solaris 8 with gcc 

Details: Platform: SunOS asafoetida 5.8 Generic_108528-04 sun4u sparc
SUNW,Ultra-60
Compiler: gcc version 2.95.2 19991024 (release)
2.1a2 from CVS of Feb 16

"make" builds the bootstrap python successfully, but fails to build any
extensions due to lack of "-fPIC" compiler option. Putting this option in
by hand allows the extensions to build. A typical error message is:

building 'struct' extension
creating build
creating build/temp.solaris-2.8-sun4u-2.1
gcc -g -O2 -Wall -Wstrict-prototypes -I.
-I/export/home0/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include 
-c /export/home0/mark/src/python/CVS/python/dist/src/Modules/structmodule.c
-o build/temp.solaris-2.8-sun4u-2.1/structmodule.o
creating build/lib.solaris-2.8-sun4u-2.1
gcc -shared build/temp.solaris-2.8-sun4u-2.1/structmodule.o
-L/usr/local/lib -o 
build/lib.solaris-2.8-sun4u-2.1/struct.so
WARNING: building of extension "struct" failed: command 'gcc' failed with
exit status 1

Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x1204     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
<unknown>                           0x1208     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
<unknown>                           0x120c     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
<unknown>                           0x1210     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
.
<lots more elided>
.
PyErr_ExceptionMatches              0xc78      
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
Py_InitModule4                      0x1c48     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
ld: fatal: relocations remain against allocatable but non-writable
sections
collect2: ld returned 1 exit status


Follow-Ups:

Date: 2001-Feb-17 16:56
By: mfavas

Comment:
I've submitted a patch to configure.in to fix this bug - patch number
103865. 
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132783&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 02:37:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 18:37:37 -0800
Subject: [Python-bugs-list] [Bug #131249] cgi.py opens too many (temporary) files
Message-ID: <E14UJjF-00067X-00@usw-sf-web3.sourceforge.net>

Bug #131249, was updated on 2001-Feb-06 04:59
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: stadt
Assigned to : akuchling
Summary: cgi.py opens too many (temporary) files

Details: cgi.FieldStorage() is used to get the contents of a webform. It
turns out that
for each <input> line, a new temporary file is opened. This causes the
script
that is using cgi.FieldStorage() to reach the webserver's limit of number
of
opened files, as described by 'ulimit -n'. The standard value for Solaris
systems
seems to be 64, so webforms with that many <input> fields cannot be dealt
with.

A solution would seem to use the same temporary filename, since only a
maxmimum one file is (temporarily) used at the same time. I did an "ls|wc
-l"
while the script was running, which showed only zeroes and ones.

(I'm using Python for CyberChair, an online paper submission and reviewing
system.
The webform under discussion has one input field for each reviewer, stating
the
papers he or she is supposed to be reviewing. One conference that is using
CyberChair
has almost 140 reviewers. Their system's open file limit is 64. Using the
same data on
a system with an open file limit of 260 _is_ able to deal with this.)

Follow-Ups:

Date: 2001-Feb-17 18:37
By: stadt

Comment:
I do *not* mean file upload fields. I stumbled upon this with a webform
that
contains 141 'simple' input fields like the form you can see here (which
'only'
contains 31 of those input fields):

http://www.cyberchair.org/cgi-cyb/genAssignPageReviewerPapers.py

(use chair/chair to login)

When the maximum number of file descriptors used per process was
increased
to 160 (by the sysadmins), the problem did not occur anymore, and the
webform
could be processed.

This was the error message I got: 

Traceback (most recent call last):
  File
"/usr/local/etc/httpd/DocumentRoot/ICML2001/cgi-bin/submitAssignRP.py",
line 144, in main
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 504, in
__init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 593, in
read_multi
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 506, in
__init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 603, in
read_single
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 623, in
read_lines
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 713, in
make_file
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/tempfile.py", line
144, in TemporaryFile
OSError: [Errno 24] Too many open files:
'/home/yara/brodley/icml2001/tmp/@26048.61'

I understand why you assume that it would concern *file* uploads, but this
is
not the case. As I reported before, it turns out that for each 'simple'
<input> field
a temporary file is used in to transfer the contents to the script that
uses the
cgi.FieldStorage() method, even if no files are being uploaded. The problem
is not
that too many files are open at the same time (which is 1 at most). It is
the *amount*
of files that is causing the troubles. If the same temporary file would be
used, this
problem would probably not have happened. 

My colleague Fred Gansevles wrote a possible solution, but mentioned that
this
might introduce the need for protection against a 'symlink attack'
(whatever
that may be). This solution(?) concentrates on the open file descriptor's
problem,
while Fred suggests a redesign of FieldStorage() would probably be
better.

import os, tempfile
AANTAL = 50

class TemporaryFile:
    def __init__(self):
        self.name = tempfile.mktemp("")
        open(self.name, 'w').close()
        self.offset = 0
    
    def seek(self, offset):
        self.offset = offset
    
    def read(self):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        data = fd.read()
        self.offset = fd.tell()
        fd.close()
        return data
    
    def write(self, data):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        fd.write(data)
        self.offset = fd.tell()
        fd.close()

    def __del__(self):
        os.unlink(self.name)

def add_fd(l, n) :
    map(lambda x,l=l: l.append(open('/dev/null')), range(n))

def add_tmp(l, n) :
    map(lambda x,l=l: l.append(TemporaryFile()), range(n))

def main ():
    import getopt, sys
    try:
        import resource
        soft, hard = resource.getrlimit (resource.RLIMIT_NOFILE)
        resource.setrlimit (resource.RLIMIT_NOFILE, (hard, hard))
    except ImportError:
        soft, hard = 64, 1024
    opts, args = getopt.getopt(sys.argv[1:], 'n:t')
    aantal = AANTAL
    tmp = add_fd
    for o, a in opts:
        if o == '-n':
            aantal = int(a)
        elif o == '-t':
            tmp = add_tmp
    print "aantal te gebruiken fd's:", aantal   #dutch; English: 'number of
fds to be used'
    print 'tmp:', tmp.func_name
    tmp_files = []
    files=[]
    tmp(tmp_files, aantal)
    try:
        add_fd(files,hard)
    except IOError:
        pass
    print "aantal vrije gebruiken fd's:", len(files)  #enlish: 'number of
free fds'

main()

Running the above code:

    python ulimit.py [-n number] [-t]
    default number = 50, while using 'real' fd-s for temporary files.
    When using the '-t' flag 'smart' temporary files are used.

    Output:

        $ python ulimit.py
        aantal te gebruiken fd's: 50
        tmp: add_fd
        aantal vrije gebruiken fd's: 970

        $ python ulimit.py -t
        aantal te gebruiken fd's: 50
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

        $ python ulimit.py -n 1000
        aantal te gebruiken fd's: 1000
        tmp: add_fd
        aantal vrije gebruiken fd's: 20

        $ python ulimit.py -n 1000 -t
        aantal te gebruiken fd's: 1000
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020
-------------------------------------------------------

Date: 2001-Feb-16 21:41
By: akuchling

Comment:
I assume you mean 64 file upload fields, right?  
Can you provide a small test program that triggers the problem?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131249&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 04:46:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 20:46:52 -0800
Subject: [Python-bugs-list] [Bug #132313] error message confusing for assignment in lambda
Message-ID: <E14ULkK-00028u-00@usw-sf-web1.sourceforge.net>

Bug #132313, was updated on 2001-Feb-14 00:45
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : tim_one
Summary: error message confusing for assignment in lambda

Details: Python 2.1a1 (#4, Feb 11 2001, 16:05:58) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> map(lambda foo: foo[0] = 4, [[1, 2]*3])
SyntaxError: keyword can't be an expression


Follow-Ups:

Date: 2001-Feb-17 20:46
By: tim_one

Comment:
I put in a hack to make this produce:
SyntaxError: lambda cannot contain assignment

This triggers if and only if the LHS test bottoms out at a lambdef.  Solves
nothing in general, but is a one-liner change that catches this kind of
case reliably, and hurts nothing else.  If the flawed lambda is embedded in
a larger expression, then this test won't trigger, but then "keyword can't
be an expression" is an *appropriate* msg.

compile.c rev 2.165.
-------------------------------------------------------

Date: 2001-Feb-14 06:42
By: gvanrossum

Comment:
Assigning to Tim Peters. My own inclination is to close this with a "Won't
Fix", because it's nearly impossible to get the parser to spit out a better
error message without completely reimplementing the parser using a
different approach. But Tim may want this to nag us more...

Background: while we would like the grammar for function arguments to be
[NAME '='] expression, our parser generator doesn't support that, and
unfortunately it has to have the form "expression ['=' expression]". Then
the code generator back-end does an additional check to make sure that if
the second expression is given (meaning this is a keyword argument), the
first expression is of the form NAME.  That's the error you're getting
here, because "lambda foo: foo[0]" happens to be a valid match for the
first expression.  I don't see an easy way to improve the error message.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132313&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 05:38:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 21:38:29 -0800
Subject: [Python-bugs-list] [Bug #132911] ConfigParser's has_option() is case-sensitive
Message-ID: <E14UMYH-0007BJ-00@usw-sf-web3.sourceforge.net>

Bug #132911, was updated on 2001-Feb-17 21:38
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: ConfigParser's has_option() is case-sensitive

Details: First, there are two methods named has_option() in ConfigParser.

Second, in both cases has_option() is case sensitive.
Fix: add option = self.optionxform(option) at the beginning of the
method.



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132911&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 05:45:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 17 Feb 2001 21:45:48 -0800
Subject: [Python-bugs-list] [Bug #132913] ConfigParser set() does not xform option
Message-ID: <E14UMfM-0002dU-00@usw-sf-web1.sourceforge.net>

Bug #132913, was updated on 2001-Feb-17 21:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: ConfigParser set() does not xform option

Details: ConfigParser's set(section,option,value) does not optionxform the
option when adding it to the section.  This is not consistent with what
happens from read().

Fix: add option=self.optionxform(option) at beginning of set()


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132913&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 08:15:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 00:15:09 -0800
Subject: [Python-bugs-list] [Bug #132921] None treated differently in cmp() / sort() in 2.1a2
Message-ID: <E14UOzt-0003E7-00@usw-sf-web2.sourceforge.net>

Bug #132921, was updated on 2001-Feb-18 00:15
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: greg
Assigned to : nobody
Summary: None treated differently in cmp() / sort() in 2.1a2

Details: In python 1.5.2 -> 2.0 the comparing None to an integer or float
appeared to always returned None as being greater.

In python 2.1a2 it appears that None is reported as being less than the
numerical types.

Looking deeper into the language reference the only thing I see that might
apply to this is in section 5.9 Comparisons. "Otherwise, objects of
different types always compare unequal, and are ordered consistently but
arbitrarily."

If the behavior of comparisons to None has changed on purpose, please
document it as a notable behavior difference in the changelog.  Also,
mentioning a defined behavior of None in the comparison chapeter would be
nice as it is a useful special case.

Intuitively I'd say making None always compare as less than anything other
than itself makes sense so bravo for fixing it if that was by design.

I'm off to fix some code that had depended on this sort order for desired
behavior. 

thanks,
Greg



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132921&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 08:30:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 00:30:36 -0800
Subject: [Python-bugs-list] [Bug #132921] None treated differently in cmp() / sort() in 2.1a2
Message-ID: <E14UPEq-00086d-00@usw-sf-web3.sourceforge.net>

Bug #132921, was updated on 2001-Feb-18 00:15
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Submitted by: greg
Assigned to : tim_one
Summary: None treated differently in cmp() / sort() in 2.1a2

Details: In python 1.5.2 -> 2.0 the comparing None to an integer or float
appeared to always returned None as being greater.

In python 2.1a2 it appears that None is reported as being less than the
numerical types.

Looking deeper into the language reference the only thing I see that might
apply to this is in section 5.9 Comparisons. "Otherwise, objects of
different types always compare unequal, and are ordered consistently but
arbitrarily."

If the behavior of comparisons to None has changed on purpose, please
document it as a notable behavior difference in the changelog.  Also,
mentioning a defined behavior of None in the comparison chapeter would be
nice as it is a useful special case.

Intuitively I'd say making None always compare as less than anything other
than itself makes sense so bravo for fixing it if that was by design.

I'm off to fix some code that had depended on this sort order for desired
behavior. 

thanks,
Greg



Follow-Ups:

Date: 2001-Feb-18 00:30
By: tim_one

Comment:
Guido did change this on purpose, but it's still not guaranteed to stay
this way across releases.

I just added this blurb to the NEWS file (revision 1.123):

- The outcome of comparing non-numeric objects of differerent types is not
defined by the language, other
than that it's arbitrary but consistent (see the Reference
Manual).  An implementation detail changed in 2.1a1 such
that None now compares less than any other object.  Code
relying on this new behavior (like code that relied on the
previous behavior) does so at its own risk.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132921&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 11:21:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 03:21:00 -0800
Subject: [Python-bugs-list] [Bug #132010] urllib and httplib fails to open url
Message-ID: <E14URtk-0004H0-00@usw-sf-web2.sourceforge.net>

Bug #132010, was updated on 2001-Feb-12 08:51
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: apederse
Assigned to : gstein
Summary: urllib and httplib fails to open url

Details: urllib and httplib fails to open the URL:
"http://www.redherring.com/". By examining network traffic a request and
response from server is taking place but python simply hangs with an
"connection reset by peer" when it tries to open this particular URL.
Fredrik Lundh had a work-around to this problem while using httplib by
doing an explicit socket.close(), however I believe that more people should
look into the problem and hopefully a fix could be available for both
urllib and httplib. The problem has been reported to fail under both
version 1.5.2 and 2.0, however I have only tested it under ver.1.5.2

for more details do also take a look at:
http://x61.deja.com/%5BST_rn=ps%5D/viewthread.xp?AN=725477609&search=thread&svcclass=dnyr&ST=PS&CONTEXT=981992343.458686528&HIT_CONTEXT=981992343.458686528&HIT_NUM=0&recnum=%3c95th67$36j$1@nnrp1.deja.com%3e%231/1&group=comp.lang.python&frpage=viewthread.xp&back=clarinet


Follow-Ups:

Date: 2001-Feb-18 03:20
By: effbot

Comment:
reassigned to greg, who wrote the 2.0 code.

summary: the redherring server requires an explicit
shutdown before it starts returning data.  From what
I can tell, httplib is doing everything by the book,
so it's probably a broken/braindead server.  But it
does appear to work with most browsers...

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

Date: 2001-Feb-13 02:15
By: tim_one

Comment:
Assigned to /F since he's already looked at this.  So what's up with
redherring.com?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132010&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 11:28:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 03:28:56 -0800
Subject: [Python-bugs-list] [Bug #132933] list.sort doesn't detect comparision errors
Message-ID: <E14US1Q-0000ix-00@usw-sf-web3.sourceforge.net>

Bug #132933, was updated on 2001-Feb-18 03:28
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: effbot
Assigned to : nobody
Summary: list.sort doesn't detect comparision errors

Details: 2.0 does the right thing:

Python 2.0 (#8, Jan 29 2001, 22:28:01) on win32
>>> a = [u"foo", "bär"]
>>> a.sort()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII decoding error: ordinal not in range(128)

2.1 doesn't:

Python 2.1a2 (#10, Feb 18 2001, 00:16:17) on win32
>>> a = [u"foo", "bär"]
>>> a.sort()
>>> a
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> a
['b\x84r', u'foo']
>>> a.sort()
>>> a = 10
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> a.sort()
>>> # hey, what's going on here?
...
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> quit
'Use Ctrl-Z plus Return to exit.'
(reboot)

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132933&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 11:40:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 03:40:32 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14USCe-0005Sq-00@usw-sf-web1.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-18 03:40
By: zessin_5

Comment:
> zessin_5, then you must have rebroken -x under  OpenVMS. Yes?

Correct. However, I have never used '-x' on OpenVMS before.

> zessin_5, how does rev 2.123 work for you under OpenVMS?

It works properly, now. Thanks, Tim.

Test scripts:
TEST_X_OPTION_01LF.PY
print 'line 1, file in Stream_LF format'
print 'line 2'

TEST_X_OPTION_01RMS.PY
print 'line 1, file in record format'
print 'line 2'

TEST_X_OPTION_02LF.PY
line_1_to_be_ignored by -x option
print 'line 2, file in Stream_LF format'
print 'line 3'

TEST_X_OPTION_02RMS.PY
line_1_to_be_ignored by -x option
print 'line 2, file in record format'
print 'line 3'

Sample run:
VMS> ! <- this is the OS prompt I have set
VMS> set VERIFY
VMS> @ TEST_X_OPTION-RUN.COM;
$ set noON
$
$ python      test_x_option_01lf.py
line 1, file in Stream_LF format
line 2
$ python  -x  test_x_option_02lf.py
line 2, file in Stream_LF format
line 3
$ python      test_x_option_01rms.py
line 1, file in record format
line 2
$ python  -x  test_x_option_02rms.py
line 2, file in record format
line 3
$
$ exit 1
VMS>


I don't understand you comments from 2001-Feb-17 12:26
about execution of '.pyc/o' files.

Am I supposed to compile the scripts and then invoke them like:
  $ python test_x.pyc
or
  $ python -x test_x.pyc
??

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

Date: 2001-Feb-17 16:17
By: tim_one

Comment:
Thought about that, but it won't fly:  the C std (whether C89 or C99)
guarantees only one character of pushback via ungetc; the typical case here
would have 2, and whether or not that works is again a platform-dependent
accident.
-------------------------------------------------------

Date: 2001-Feb-17 14:39
By: mpmak

Comment:

Inside NT works.
Thanks.

PS same effect without fseek/ftell:

int ispyc = 0;
int bytesread=fread(buf, 1, 2, fp);
ispyc = bytesread == 2 &&
  ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
while( !ispyc && bytesread>0 ){
 ungetc(buf[--bytesread], fp);
}

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

Date: 2001-Feb-17 14:09
By: tim_one

Comment:
Please try pythonrun.c rev 2.123.

Since fseek is a platform-dependent accident in text mode, I don't want to
use that at all anymore.

zessin_5, how does rev 2.123 work for you under OpenVMS?  I won't close
this bug for a few days pending your answer.
-------------------------------------------------------

Date: 2001-Feb-17 13:45
By: mpmak

Comment:

I have tested it on Windows NT 4.0,MSVC 6.0 SP4, with python from cvs
and:

-x - works as expected inside cmd files
*.py - are compiled/executed properly
*.pyc - python can execute pyc files too

linen umbers in buggy cmd/py files are shown corectly, in any case this
script fails when executing line 3:

#@python -x "%~f0" %* & goto :EOF
print 'ok'
makeanerror

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

Date: 2001-Feb-17 13:31
By: tim_one

Comment:
zessin_5, then you must have rebroken -x under OpenVMS.  Yes?

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

Date: 2001-Feb-17 13:27
By: tim_one

Comment:
Sorry, can't figure out what you think that code accomplishes.  Did you try
an example using -x?  Windows is the primary reason -x exists, so no hack
that leaves -x broken on Windows is acceptable.  The getc/ungetc business
is needed so that in *case* -x was specified (and without a change to the C
API, we have no way to know whether it was at this point), the \n that -x
ungetc'ed gets pushed back.  Else line numbers in tracebacks are off by one
under -x, and that's not acceptable either.
-------------------------------------------------------

Date: 2001-Feb-17 13:11
By: mpmak

Comment:

Brute force hack helps - at last for MS:

#ifdef _MSC_VER
		const long currentpos = ftell(fp);
		int ispyc = fread(buf, 1, 2, fp) == 2 &&
		        ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
		fseek(fp, currentpos, SEEK_SET);
#else
... current CVS code goes here
#endif

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

Date: 2001-Feb-17 12:56
By: zessin_5

Comment:
Additional info:

A change (in pythonrun.c) also broke (partly)
processing on OpenVMS.

The same effect (doubling the first character)
happens when the file is not in stream linefeed
format - otherwise it works as before.
Text editors, however, create files in record
format.

The problem is that the C library on OpenVMS
can only seek on record boundaries - I don't
want to go into too much detail, here.

I've restored the old code from version 2.1a2
in routine 'maybe_pyc_file()' in my copy and
it started working again.
-------------------------------------------------------

Date: 2001-Feb-17 12:47
By: tim_one

Comment:
Indeed, from stepping thru MS's ftell(), they do a great deal of expensive
fiddling for text-mode streams *assuming* that every \n in the stdio buffer
was originally an \r\n on disk.  When that isn't true, the adjustments they
make yield bizarre results.  We can't do anything about that.
-------------------------------------------------------

Date: 2001-Feb-17 12:26
By: tim_one

Comment:
I'm not sure this can be fixed with reasonable effort.

The patch that allowed .pyc files to get executed from the command-line,
and whether or not they have a .pyc/.pyo extension, broke the -x option
(skip first line), by rewinding the file to see whether it begins with the
right magic number.  That undid what -x does (i.e., skip over the first
line).

So I slopped in another hack to restore the file position in case (as is in
fact almost always the case) the .pyc magic-number hack didn't find what it
was looking for.

And there's the rub.  It *turns out* that, using MS's libraries, and
assuming FILE* fp is at the start of the text-mode stream, after

int ch = getc(fp);
long pos = ftell(fp);

then ch is reliably set to the first character in the file.  However, pos
is set to 1 if and only if the first line *ends* with \r\n.  If it ends
with plain \n, pos is left at 0.  This is bizarre and darned hard to
explain, but that is the way it works.

The .pyc hackery later fseek's back to pos and does ungetc(ch).  Since in
your case pos was set to 0, that ends up "stuttering" the first character
(ungetc('p') effectively puts an extra 'p' at the start of the file,
because pos was left at 0).

Since files with Unix line-ends are not proper text-mode files under
Windows, I doubt Microsoft would consider their behavior buggy here, and
neither would the C std (C guarantees very little about how text mode
works).

And I don't see any hope of fixing it short of either:

1. Opening .py files in binary mode and doing line-end translations
ourselves (a good idea, actually, but A Project).

or

2. Redoing the .pyc hack from scratch:  it should be done *before* -x
processing.  But that may require changing Python's C API.

In short, it's a mess.
-------------------------------------------------------

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 11:46:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 03:46:20 -0800
Subject: [Python-bugs-list] [Bug #132817] test_ucn fails on OpenVMS - AssertionError
Message-ID: <E14USIG-0000pq-00@usw-sf-web3.sourceforge.net>

Bug #132817, was updated on 2001-Feb-17 05:54
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Submitted by: zessin_5
Assigned to : effbot
Summary: test_ucn fails on OpenVMS - AssertionError

Details: test_ucn

On OpenVMS, this test fails with the following error message:

test test_ucn crashed -- exceptions.AssertionError: failed
 to raise an exception when given a bogus character name


How can I diagnose this?


Follow-Ups:

Date: 2001-Feb-18 03:46
By: effbot

Comment:
thanks for spotting the typo.  just wish I knew why
this didn't show up on any other platform...
-------------------------------------------------------

Date: 2001-Feb-17 14:37
By: zessin_5

Comment:
Here is the result from my debugging:

UNICODEOBJECT.C
if (!ucnhash_CAPI->getcode(start, endBrace-start, &chr)) {

calls:
UNICODEDATA.C:
getcode(const char* name, int namelen, Py_UCS4* code)
{

There are 4 'return's in getcode().
After I replace the 'return -1;' with 'return 0;'
I get the exceptions.
-------------------------------------------------------

Date: 2001-Feb-17 10:20
By: tim_one

Comment:
Assigned to /F.

zessin_5, look at test_ucn.py, if you want.  The error in question is
raised in only one place, verifying that

"\N{blah}"

raises UnicodeError when passed thru unicode-escape.  Don't know why it's
not on your platform.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132817&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 14:36:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 06:36:20 -0800
Subject: [Python-bugs-list] [Bug #129661] library-dirs option in setup.cfg crashes distutils
Message-ID: <E14UUwm-0006zX-00@usw-sf-web1.sourceforge.net>

Bug #129661, was updated on 2001-Jan-22 02:16
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: larsga
Assigned to : akuchling
Summary: library-dirs option in setup.cfg crashes distutils

Details: When I set 

library-dirs = /usr/src/own/sp-1.3.4/lib

under [build_ext] in my setup.cfg file, I get a traceback from distutils
that looks like this:

[larsga@localhost pysp]$ python setup.py build
running build
running build_ext
building 'pysp' extension
skipping pyspmodule.cxx (build/temp.linux-i686-2.0/pyspmodule.o
up-to-date)
Traceback (most recent call last):
  File "setup.py", line 14, in ?
    license = "BSD-like")
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/core.py",
line 138, in setup
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/dist.py",
line 829, in run_commands
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/dist.py",
line 849, in run_command
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/command/build.py",
line 106, in run
  File "/usr/local/lib/python2.0/cmd.py", line 328, in run_command
    print "\n"
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/dist.py",
line 849, in run_command
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/command/build_ext.py",
line 225, in run
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/command/build_ext.py",
line 441, in build_extensions
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/ccompiler.py",
line 662, in link_shared_object
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/unixccompiler.py",
line 208, in link
  File
"/var/tmp/BeOpen-Python-2.0-root/usr/local/lib/python2.0/distutils/ccompiler.py",
line 430, in _fix_lib_args
TypeError: can only concatenate list (not "string") to list


If I remove the option, my extension won't build, because gcc can't find
the needed library.

Follow-Ups:

Date: 2001-Feb-18 06:36
By: larsga

Comment:
Did a cvs update and found that in the version currently in the CVS tree
this problem is fixed.
-------------------------------------------------------

Date: 2001-Feb-16 21:16
By: akuchling

Comment:
I believe this bug was fixed by patch #102971, and therefore isn't 
present in the current CVS tree.  Can you confirm this (perhaps by just
applying the patch) and let me know if that's correct?


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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129661&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 15:30:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 07:30:59 -0800
Subject: [Python-bugs-list] [Bug #132933] list.sort doesn't detect comparision errors
Message-ID: <E14UVnf-0000AS-00@usw-sf-web1.sourceforge.net>

Bug #132933, was updated on 2001-Feb-18 03:28
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: effbot
Assigned to : nobody
Summary: list.sort doesn't detect comparision errors

Details: 2.0 does the right thing:

Python 2.0 (#8, Jan 29 2001, 22:28:01) on win32
>>> a = [u"foo", "bär"]
>>> a.sort()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII decoding error: ordinal not in range(128)

2.1 doesn't:

Python 2.1a2 (#10, Feb 18 2001, 00:16:17) on win32
>>> a = [u"foo", "bär"]
>>> a.sort()
>>> a
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> a
['b\x84r', u'foo']
>>> a.sort()
>>> a = 10
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> a.sort()
>>> # hey, what's going on here?
...
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> quit
'Use Ctrl-Z plus Return to exit.'
(reboot)

Follow-Ups:

Date: 2001-Feb-18 07:30
By: tim_one

Comment:
Under a debug build,

Python 2.1a2 (#10, Feb  8 2001, 22:47:05) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> a = [u"foo", "bär"]
[5219 refs]
>>> a.sort()
XXX undetected error
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII decoding error: ordinal not in range(128)
[5262 refs]
>>>

"XXX undetected error" looks like a good clue.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132933&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 15:51:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 07:51:35 -0800
Subject: [Python-bugs-list] [Bug #132933] list.sort doesn't detect comparision errors
Message-ID: <E14UW7b-00070h-00@usw-sf-web2.sourceforge.net>

Bug #132933, was updated on 2001-Feb-18 03:28
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: effbot
Assigned to : gvanrossum
Summary: list.sort doesn't detect comparision errors

Details: 2.0 does the right thing:

Python 2.0 (#8, Jan 29 2001, 22:28:01) on win32
>>> a = [u"foo", "bär"]
>>> a.sort()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII decoding error: ordinal not in range(128)

2.1 doesn't:

Python 2.1a2 (#10, Feb 18 2001, 00:16:17) on win32
>>> a = [u"foo", "bär"]
>>> a.sort()
>>> a
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> a
['b\x84r', u'foo']
>>> a.sort()
>>> a = 10
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> a.sort()
>>> # hey, what's going on here?
...
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> quit
'Use Ctrl-Z plus Return to exit.'
(reboot)

Follow-Ups:

Date: 2001-Feb-18 07:51
By: tim_one

Comment:
Assigned to Guido, boosted priority.

In try_3way_to_rich_compare,

if (c >= 2) c = default_3way_compare(v, w);

triggers and sets c to -2.  But then that's treated like an ordinary return
value for Py_LT, and try_3way_to_rich_compare returns Py_True leaving the
error sitting on the floor.

I figure you know a lot better than I what may have changed here since 2.0
...
-------------------------------------------------------

Date: 2001-Feb-18 07:30
By: tim_one

Comment:
Under a debug build,

Python 2.1a2 (#10, Feb  8 2001, 22:47:05) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> a = [u"foo", "bär"]
[5219 refs]
>>> a.sort()
XXX undetected error
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII decoding error: ordinal not in range(128)
[5262 refs]
>>>

"XXX undetected error" looks like a good clue.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132933&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 16:34:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 08:34:47 -0800
Subject: [Python-bugs-list] [Bug #132817] test_ucn fails on OpenVMS - AssertionError
Message-ID: <E14UWnP-0003ls-00@usw-sf-web3.sourceforge.net>

Bug #132817, was updated on 2001-Feb-17 05:54
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: zessin_5
Assigned to : effbot
Summary: test_ucn fails on OpenVMS - AssertionError

Details: test_ucn

On OpenVMS, this test fails with the following error message:

test test_ucn crashed -- exceptions.AssertionError: failed
 to raise an exception when given a bogus character name


How can I diagnose this?


Follow-Ups:

Date: 2001-Feb-18 08:34
By: tim_one

Comment:
/F, I'm re-opening this until it's understood.  It's clear that the test
"worked" by accident before, yes?  I stepped thru it ("N{blah}") in the
debugger on Windows, under the old code.  The reason it worked then is
that, in PyUnicode_DecodeUnicodeEscape, the stack vrbl "chr" remained
uninitialized all the way to label "store:", where a series of tests then
checked this stack trash against various ranges.  On Windows the trash
happened to be the too-large-for-Unicode 0x0063f9dc, so triggered a
different error by accident.  Presumably under OpenVMS, the trash passed
those tests by accident.

Perhaps it's impossible to ever test stack trash now, but I'd feel better
if the code covered its ass there anyway.  You?
-------------------------------------------------------

Date: 2001-Feb-18 03:46
By: effbot

Comment:
thanks for spotting the typo.  just wish I knew why
this didn't show up on any other platform...
-------------------------------------------------------

Date: 2001-Feb-17 14:37
By: zessin_5

Comment:
Here is the result from my debugging:

UNICODEOBJECT.C
if (!ucnhash_CAPI->getcode(start, endBrace-start, &chr)) {

calls:
UNICODEDATA.C:
getcode(const char* name, int namelen, Py_UCS4* code)
{

There are 4 'return's in getcode().
After I replace the 'return -1;' with 'return 0;'
I get the exceptions.
-------------------------------------------------------

Date: 2001-Feb-17 10:20
By: tim_one

Comment:
Assigned to /F.

zessin_5, look at test_ucn.py, if you want.  The error in question is
raised in only one place, verifying that

"\N{blah}"

raises UnicodeError when passed thru unicode-escape.  Don't know why it's
not on your platform.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132817&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 19:35:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 11:35:47 -0800
Subject: [Python-bugs-list] [Bug #132817] test_ucn fails on OpenVMS - AssertionError
Message-ID: <E14UZcZ-0002UP-00@usw-sf-web1.sourceforge.net>

Bug #132817, was updated on 2001-Feb-17 05:54
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: zessin_5
Assigned to : effbot
Summary: test_ucn fails on OpenVMS - AssertionError

Details: test_ucn

On OpenVMS, this test fails with the following error message:

test test_ucn crashed -- exceptions.AssertionError: failed
 to raise an exception when given a bogus character name


How can I diagnose this?


Follow-Ups:

Date: 2001-Feb-18 11:35
By: effbot

Comment:
Tim, "getcode" is supposed to set the "chr" value if it returns non-zero. 
After Uwe's fix, this is exactly what it does.

But DecodeUnicodeEscape is rather messy; I've discovered a few other cases
where it can misbehave.  I'll do something about it asap. /F
-------------------------------------------------------

Date: 2001-Feb-18 08:34
By: tim_one

Comment:
/F, I'm re-opening this until it's understood.  It's clear that the test
"worked" by accident before, yes?  I stepped thru it ("N{blah}") in the
debugger on Windows, under the old code.  The reason it worked then is
that, in PyUnicode_DecodeUnicodeEscape, the stack vrbl "chr" remained
uninitialized all the way to label "store:", where a series of tests then
checked this stack trash against various ranges.  On Windows the trash
happened to be the too-large-for-Unicode 0x0063f9dc, so triggered a
different error by accident.  Presumably under OpenVMS, the trash passed
those tests by accident.

Perhaps it's impossible to ever test stack trash now, but I'd feel better
if the code covered its ass there anyway.  You?
-------------------------------------------------------

Date: 2001-Feb-18 03:46
By: effbot

Comment:
thanks for spotting the typo.  just wish I knew why
this didn't show up on any other platform...
-------------------------------------------------------

Date: 2001-Feb-17 14:37
By: zessin_5

Comment:
Here is the result from my debugging:

UNICODEOBJECT.C
if (!ucnhash_CAPI->getcode(start, endBrace-start, &chr)) {

calls:
UNICODEDATA.C:
getcode(const char* name, int namelen, Py_UCS4* code)
{

There are 4 'return's in getcode().
After I replace the 'return -1;' with 'return 0;'
I get the exceptions.
-------------------------------------------------------

Date: 2001-Feb-17 10:20
By: tim_one

Comment:
Assigned to /F.

zessin_5, look at test_ucn.py, if you want.  The error in question is
raised in only one place, verifying that

"\N{blah}"

raises UnicodeError when passed thru unicode-escape.  Don't know why it's
not on your platform.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132817&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 20:09:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 12:09:42 -0800
Subject: [Python-bugs-list] [Bug #132817] test_ucn fails on OpenVMS - AssertionError
Message-ID: <E14Ua9O-0005G9-00@usw-sf-web3.sourceforge.net>

Bug #132817, was updated on 2001-Feb-17 05:54
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: zessin_5
Assigned to : effbot
Summary: test_ucn fails on OpenVMS - AssertionError

Details: test_ucn

On OpenVMS, this test fails with the following error message:

test test_ucn crashed -- exceptions.AssertionError: failed
 to raise an exception when given a bogus character name


How can I diagnose this?


Follow-Ups:

Date: 2001-Feb-18 12:09
By: tim_one

Comment:
I just had in mind initializing chr to a known-bogus value and assert'ing
it doesn't still have that value when it's finally referenced, so that a
reoccurrence of this (or similar) bug won't pass by accident again.

I understand that the code was intended to work as you say, but better safe
than to trust that all future maintainers will figure that out when they're
hacking in the middle of the 200+ lines of code across which this
undocumented invariant is supposed to hold.  Goodness, the code even
initializes p, despite that it's set again within a mere dozen lines
<wink>.
-------------------------------------------------------

Date: 2001-Feb-18 11:35
By: effbot

Comment:
Tim, "getcode" is supposed to set the "chr" value if it returns non-zero. 
After Uwe's fix, this is exactly what it does.

But DecodeUnicodeEscape is rather messy; I've discovered a few other cases
where it can misbehave.  I'll do something about it asap. /F
-------------------------------------------------------

Date: 2001-Feb-18 08:34
By: tim_one

Comment:
/F, I'm re-opening this until it's understood.  It's clear that the test
"worked" by accident before, yes?  I stepped thru it ("N{blah}") in the
debugger on Windows, under the old code.  The reason it worked then is
that, in PyUnicode_DecodeUnicodeEscape, the stack vrbl "chr" remained
uninitialized all the way to label "store:", where a series of tests then
checked this stack trash against various ranges.  On Windows the trash
happened to be the too-large-for-Unicode 0x0063f9dc, so triggered a
different error by accident.  Presumably under OpenVMS, the trash passed
those tests by accident.

Perhaps it's impossible to ever test stack trash now, but I'd feel better
if the code covered its ass there anyway.  You?
-------------------------------------------------------

Date: 2001-Feb-18 03:46
By: effbot

Comment:
thanks for spotting the typo.  just wish I knew why
this didn't show up on any other platform...
-------------------------------------------------------

Date: 2001-Feb-17 14:37
By: zessin_5

Comment:
Here is the result from my debugging:

UNICODEOBJECT.C
if (!ucnhash_CAPI->getcode(start, endBrace-start, &chr)) {

calls:
UNICODEDATA.C:
getcode(const char* name, int namelen, Py_UCS4* code)
{

There are 4 'return's in getcode().
After I replace the 'return -1;' with 'return 0;'
I get the exceptions.
-------------------------------------------------------

Date: 2001-Feb-17 10:20
By: tim_one

Comment:
Assigned to /F.

zessin_5, look at test_ucn.py, if you want.  The error in question is
raised in only one place, verifying that

"\N{blah}"

raises UnicodeError when passed thru unicode-escape.  Don't know why it's
not on your platform.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132817&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 20:24:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 12:24:06 -0800
Subject: [Python-bugs-list] [Bug #132850] unix line terminator on windows
Message-ID: <E14UaNK-0005Lq-00@usw-sf-web3.sourceforge.net>

Bug #132850, was updated on 2001-Feb-17 10:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 6
Submitted by: mpmak
Assigned to : tim_one
Summary: unix line terminator on windows

Details: 
Syntax/Name error when first script line is terminated only by \x0a - not
\x0d\x0a

this does totally nothing - every line terminated with \x0a
#
print '1 line'
print '2 line'

NameError error - name p is not defined
print '1 line'
print '2 line'

when only script has single line:
print '1 line'

SyntaxError but traceback is funny:
pprint '1 line'
              ^
SyntaxError: invalid syntax


Follow-Ups:

Date: 2001-Feb-18 12:24
By: tim_one

Comment:
Python scripts usually start on Unix with a line like

#! /usr/bin/env python

That way Unixoids can just say

$ myscript

at the command line instead of

$ python myscript

The "#!" is a Unixism that the OS understands.  Since it starts with #,
Python treats it as a comment.

Several other platforms support *similar* tricks, but they don't start with
#.  In that case -x is intended to be used, like starting your script
with

*&$%^ python -x %*

where "*&$%^" is whatever string of gibberish characters the platform uses
that mean the same thing as Unix "#!".

And that's the only thing -x is good for.  So if OpenVMS doesn't have
something like that, don't worry about -x.

WRT .pyc and .pyo files, yes,

$ python test_x.pyc

is *a* proper way to test that.  "-x" makes no sense at all when running
compiled bytecode, so I don't even care if that combination blows up.

The test above is too easy, though, because Python notices that the
filename ends with ".pyc", and skips all the hard work of *guessing*
whether the file passed to it is compiled bytecode.  So a better test is to
rename the bytecode file so Python can't recognize that it is bytecode just
from its name.  That's much trickier to get right across platforms, so that
would still be a valuable test to run.  Like (of course I don't know how to
spell this on your box):

$ copy test_x.pyc mystery
$ python mystery

Thanks!  In any case, the original bug appears fixed so I'm closing this
now.  If you still have a problem with something above, let's open a new
report so it says "OpenVMS" in the Summary line (we ran out of Windows
problems here).
-------------------------------------------------------

Date: 2001-Feb-18 03:40
By: zessin_5

Comment:
> zessin_5, then you must have rebroken -x under  OpenVMS. Yes?

Correct. However, I have never used '-x' on OpenVMS before.

> zessin_5, how does rev 2.123 work for you under OpenVMS?

It works properly, now. Thanks, Tim.

Test scripts:
TEST_X_OPTION_01LF.PY
print 'line 1, file in Stream_LF format'
print 'line 2'

TEST_X_OPTION_01RMS.PY
print 'line 1, file in record format'
print 'line 2'

TEST_X_OPTION_02LF.PY
line_1_to_be_ignored by -x option
print 'line 2, file in Stream_LF format'
print 'line 3'

TEST_X_OPTION_02RMS.PY
line_1_to_be_ignored by -x option
print 'line 2, file in record format'
print 'line 3'

Sample run:
VMS> ! <- this is the OS prompt I have set
VMS> set VERIFY
VMS> @ TEST_X_OPTION-RUN.COM;
$ set noON
$
$ python      test_x_option_01lf.py
line 1, file in Stream_LF format
line 2
$ python  -x  test_x_option_02lf.py
line 2, file in Stream_LF format
line 3
$ python      test_x_option_01rms.py
line 1, file in record format
line 2
$ python  -x  test_x_option_02rms.py
line 2, file in record format
line 3
$
$ exit 1
VMS>


I don't understand you comments from 2001-Feb-17 12:26
about execution of '.pyc/o' files.

Am I supposed to compile the scripts and then invoke them like:
  $ python test_x.pyc
or
  $ python -x test_x.pyc
??

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

Date: 2001-Feb-17 16:17
By: tim_one

Comment:
Thought about that, but it won't fly:  the C std (whether C89 or C99)
guarantees only one character of pushback via ungetc; the typical case here
would have 2, and whether or not that works is again a platform-dependent
accident.
-------------------------------------------------------

Date: 2001-Feb-17 14:39
By: mpmak

Comment:

Inside NT works.
Thanks.

PS same effect without fseek/ftell:

int ispyc = 0;
int bytesread=fread(buf, 1, 2, fp);
ispyc = bytesread == 2 &&
  ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
while( !ispyc && bytesread>0 ){
 ungetc(buf[--bytesread], fp);
}

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

Date: 2001-Feb-17 14:09
By: tim_one

Comment:
Please try pythonrun.c rev 2.123.

Since fseek is a platform-dependent accident in text mode, I don't want to
use that at all anymore.

zessin_5, how does rev 2.123 work for you under OpenVMS?  I won't close
this bug for a few days pending your answer.
-------------------------------------------------------

Date: 2001-Feb-17 13:45
By: mpmak

Comment:

I have tested it on Windows NT 4.0,MSVC 6.0 SP4, with python from cvs
and:

-x - works as expected inside cmd files
*.py - are compiled/executed properly
*.pyc - python can execute pyc files too

linen umbers in buggy cmd/py files are shown corectly, in any case this
script fails when executing line 3:

#@python -x "%~f0" %* & goto :EOF
print 'ok'
makeanerror

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

Date: 2001-Feb-17 13:31
By: tim_one

Comment:
zessin_5, then you must have rebroken -x under OpenVMS.  Yes?

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

Date: 2001-Feb-17 13:27
By: tim_one

Comment:
Sorry, can't figure out what you think that code accomplishes.  Did you try
an example using -x?  Windows is the primary reason -x exists, so no hack
that leaves -x broken on Windows is acceptable.  The getc/ungetc business
is needed so that in *case* -x was specified (and without a change to the C
API, we have no way to know whether it was at this point), the \n that -x
ungetc'ed gets pushed back.  Else line numbers in tracebacks are off by one
under -x, and that's not acceptable either.
-------------------------------------------------------

Date: 2001-Feb-17 13:11
By: mpmak

Comment:

Brute force hack helps - at last for MS:

#ifdef _MSC_VER
		const long currentpos = ftell(fp);
		int ispyc = fread(buf, 1, 2, fp) == 2 &&
		        ((unsigned int)buf[1]<<8 | buf[0]) == halfmagic;
		fseek(fp, currentpos, SEEK_SET);
#else
... current CVS code goes here
#endif

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

Date: 2001-Feb-17 12:56
By: zessin_5

Comment:
Additional info:

A change (in pythonrun.c) also broke (partly)
processing on OpenVMS.

The same effect (doubling the first character)
happens when the file is not in stream linefeed
format - otherwise it works as before.
Text editors, however, create files in record
format.

The problem is that the C library on OpenVMS
can only seek on record boundaries - I don't
want to go into too much detail, here.

I've restored the old code from version 2.1a2
in routine 'maybe_pyc_file()' in my copy and
it started working again.
-------------------------------------------------------

Date: 2001-Feb-17 12:47
By: tim_one

Comment:
Indeed, from stepping thru MS's ftell(), they do a great deal of expensive
fiddling for text-mode streams *assuming* that every \n in the stdio buffer
was originally an \r\n on disk.  When that isn't true, the adjustments they
make yield bizarre results.  We can't do anything about that.
-------------------------------------------------------

Date: 2001-Feb-17 12:26
By: tim_one

Comment:
I'm not sure this can be fixed with reasonable effort.

The patch that allowed .pyc files to get executed from the command-line,
and whether or not they have a .pyc/.pyo extension, broke the -x option
(skip first line), by rewinding the file to see whether it begins with the
right magic number.  That undid what -x does (i.e., skip over the first
line).

So I slopped in another hack to restore the file position in case (as is in
fact almost always the case) the .pyc magic-number hack didn't find what it
was looking for.

And there's the rub.  It *turns out* that, using MS's libraries, and
assuming FILE* fp is at the start of the text-mode stream, after

int ch = getc(fp);
long pos = ftell(fp);

then ch is reliably set to the first character in the file.  However, pos
is set to 1 if and only if the first line *ends* with \r\n.  If it ends
with plain \n, pos is left at 0.  This is bizarre and darned hard to
explain, but that is the way it works.

The .pyc hackery later fseek's back to pos and does ungetc(ch).  Since in
your case pos was set to 0, that ends up "stuttering" the first character
(ungetc('p') effectively puts an extra 'p' at the start of the file,
because pos was left at 0).

Since files with Unix line-ends are not proper text-mode files under
Windows, I doubt Microsoft would consider their behavior buggy here, and
neither would the C std (C guarantees very little about how text mode
works).

And I don't see any hope of fixing it short of either:

1. Opening .py files in binary mode and doing line-end translations
ourselves (a good idea, actually, but A Project).

or

2. Redoing the .pyc hack from scratch:  it should be done *before* -x
processing.  But that may require changing Python's C API.

In short, it's a mess.
-------------------------------------------------------

Date: 2001-Feb-17 11:18
By: tim_one

Comment:
Bizarre!  Assigned to me.  Worked OK in 2.0, and no idea how it could have
got broken.  Well, in truth Python never did anything to make this work, it
was simply that the MS stdio library delivered \n regardless of whether \n
or \r\n terminated a line.  That is, it was *nice* that it worked, but in
truth it was an accident.  Later.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132850&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 20:54:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 12:54:18 -0800
Subject: [Python-bugs-list] [Bug #132815] getname() already in use by OS
Message-ID: <E14UaqY-0000ZA-00@usw-sf-web2.sourceforge.net>

Bug #132815, was updated on 2001-Feb-17 05:47
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: zessin_5
Assigned to : effbot
Summary: getname() already in use by OS

Details: There is a name-clash on OpenVMS.

modules/unicodedata.c  defines a function named 'getname'.
This collides with a function that is defined in OpenVMS's
include file '<unixio.h>'.

Here is an extract from the documentation:
]getname
]
]   Returns the file specification associated with a file descriptor.
]
]   Format
]
]   #include   <unixio.h>
]
]   char  getname   (int file_desc , char  buffer, . . . );
 [...]
]   Description
]
]   This function places the file specification in the area
] pointed to by buffer and returns that address.  The area
] pointed to by buffer should be an array large enough to
] contain a fully qualified file specification (the maximum
] length is 256 characters).

Note: 'getname' is also used in include/ucnhash.h

I guess that 'getname' does also exist on other operating
systems, but might just be included by a different header
file. Can this be changed, please?


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132815&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 21:02:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 13:02:11 -0800
Subject: [Python-bugs-list] [Bug #130748] re punts on "^*"
Message-ID: <E14UayB-0003Gh-00@usw-sf-web1.sourceforge.net>

Bug #130748, was updated on 2001-Feb-01 13:53
Here is a current snapshot of the bug.

Project: Python
Category: Regular Expressions
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: dspguru
Assigned to : effbot
Summary: re punts on "^*"

Details: I don't know if this is a "bug" or it's a "just don't do that",
but here's something I just learned not to accidently do:

ActivePython 2.0, build 202 (ActiveState Tool Corp.)
based on Python 2.0 (#8, Oct 19 2000, 11:30:05) [MSC 32 bit (Intel)] on
win32
Type "copyright", "credits" or "license" for more information.
>>> import re
>>> r = re.compile('^*')
>>> s = 'asdf'
>>> r.match(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: maximum recursion limit exceeded

I guess in an ideal world, this would somehow be trapped out in re's
compilation process (though maybe that would cause more overhead than it's
worth.)

special-cases-aren't-special-enough-to-trap-out
though-safety-beats-speed-ly y'rs,

=g2

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130748&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 22:07:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 14:07:04 -0800
Subject: [Python-bugs-list] [Bug #132815] getname() already in use by OS
Message-ID: <E14Ubyy-0003rN-00@usw-sf-web1.sourceforge.net>

Bug #132815, was updated on 2001-Feb-17 05:47
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Submitted by: zessin_5
Assigned to : effbot
Summary: getname() already in use by OS

Details: There is a name-clash on OpenVMS.

modules/unicodedata.c  defines a function named 'getname'.
This collides with a function that is defined in OpenVMS's
include file '<unixio.h>'.

Here is an extract from the documentation:
]getname
]
]   Returns the file specification associated with a file descriptor.
]
]   Format
]
]   #include   <unixio.h>
]
]   char  getname   (int file_desc , char  buffer, . . . );
 [...]
]   Description
]
]   This function places the file specification in the area
] pointed to by buffer and returns that address.  The area
] pointed to by buffer should be an array large enough to
] contain a fully qualified file specification (the maximum
] length is 256 characters).

Note: 'getname' is also used in include/ucnhash.h

I guess that 'getname' does also exist on other operating
systems, but might just be included by a different header
file. Can this be changed, please?


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132815&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 22:08:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 14:08:02 -0800
Subject: [Python-bugs-list] [Bug #131249] cgi.py opens too many (temporary) files
Message-ID: <E14Ubzu-00013D-00@usw-sf-web2.sourceforge.net>

Bug #131249, was updated on 2001-Feb-06 04:59
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: stadt
Assigned to : akuchling
Summary: cgi.py opens too many (temporary) files

Details: cgi.FieldStorage() is used to get the contents of a webform. It
turns out that
for each <input> line, a new temporary file is opened. This causes the
script
that is using cgi.FieldStorage() to reach the webserver's limit of number
of
opened files, as described by 'ulimit -n'. The standard value for Solaris
systems
seems to be 64, so webforms with that many <input> fields cannot be dealt
with.

A solution would seem to use the same temporary filename, since only a
maxmimum one file is (temporarily) used at the same time. I did an "ls|wc
-l"
while the script was running, which showed only zeroes and ones.

(I'm using Python for CyberChair, an online paper submission and reviewing
system.
The webform under discussion has one input field for each reviewer, stating
the
papers he or she is supposed to be reviewing. One conference that is using
CyberChair
has almost 140 reviewers. Their system's open file limit is 64. Using the
same data on
a system with an open file limit of 260 _is_ able to deal with this.)

Follow-Ups:

Date: 2001-Feb-18 14:08
By: akuchling

Comment:
Ah, I see; the traceback makes this much clearer.  When you're uploading a
file, everything in the form is sent as 
a MIME document in the body; every field is accompanied by 
a boundary separator and Content-Disposition header.
In multipart mode, cgi.py copies each field into a temporary file.  

The first idea I had was to only use tempfiles for the actual upload field;
unfortunately, that doesn't help because the upload field isn't special,
and cgi.py has no way to know which it is ahead of time.

Possible second approach: measure the size of the resulting file; if it's
less than some threshold (1K? 10K?), read its contents into memory and
close the tempfile.  This means only the largest fields will require that a
file descriptor be kept open.  I'll explore this more after beta1.



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

Date: 2001-Feb-17 18:37
By: stadt

Comment:
I do *not* mean file upload fields. I stumbled upon this with a webform
that
contains 141 'simple' input fields like the form you can see here (which
'only'
contains 31 of those input fields):

http://www.cyberchair.org/cgi-cyb/genAssignPageReviewerPapers.py

(use chair/chair to login)

When the maximum number of file descriptors used per process was
increased
to 160 (by the sysadmins), the problem did not occur anymore, and the
webform
could be processed.

This was the error message I got: 

Traceback (most recent call last):
  File
"/usr/local/etc/httpd/DocumentRoot/ICML2001/cgi-bin/submitAssignRP.py",
line 144, in main
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 504, in
__init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 593, in
read_multi
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 506, in
__init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 603, in
read_single
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 623, in
read_lines
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 713, in
make_file
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/tempfile.py", line
144, in TemporaryFile
OSError: [Errno 24] Too many open files:
'/home/yara/brodley/icml2001/tmp/@26048.61'

I understand why you assume that it would concern *file* uploads, but this
is
not the case. As I reported before, it turns out that for each 'simple'
<input> field
a temporary file is used in to transfer the contents to the script that
uses the
cgi.FieldStorage() method, even if no files are being uploaded. The problem
is not
that too many files are open at the same time (which is 1 at most). It is
the *amount*
of files that is causing the troubles. If the same temporary file would be
used, this
problem would probably not have happened. 

My colleague Fred Gansevles wrote a possible solution, but mentioned that
this
might introduce the need for protection against a 'symlink attack'
(whatever
that may be). This solution(?) concentrates on the open file descriptor's
problem,
while Fred suggests a redesign of FieldStorage() would probably be
better.

import os, tempfile
AANTAL = 50

class TemporaryFile:
    def __init__(self):
        self.name = tempfile.mktemp("")
        open(self.name, 'w').close()
        self.offset = 0
    
    def seek(self, offset):
        self.offset = offset
    
    def read(self):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        data = fd.read()
        self.offset = fd.tell()
        fd.close()
        return data
    
    def write(self, data):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        fd.write(data)
        self.offset = fd.tell()
        fd.close()

    def __del__(self):
        os.unlink(self.name)

def add_fd(l, n) :
    map(lambda x,l=l: l.append(open('/dev/null')), range(n))

def add_tmp(l, n) :
    map(lambda x,l=l: l.append(TemporaryFile()), range(n))

def main ():
    import getopt, sys
    try:
        import resource
        soft, hard = resource.getrlimit (resource.RLIMIT_NOFILE)
        resource.setrlimit (resource.RLIMIT_NOFILE, (hard, hard))
    except ImportError:
        soft, hard = 64, 1024
    opts, args = getopt.getopt(sys.argv[1:], 'n:t')
    aantal = AANTAL
    tmp = add_fd
    for o, a in opts:
        if o == '-n':
            aantal = int(a)
        elif o == '-t':
            tmp = add_tmp
    print "aantal te gebruiken fd's:", aantal   #dutch; English: 'number of
fds to be used'
    print 'tmp:', tmp.func_name
    tmp_files = []
    files=[]
    tmp(tmp_files, aantal)
    try:
        add_fd(files,hard)
    except IOError:
        pass
    print "aantal vrije gebruiken fd's:", len(files)  #enlish: 'number of
free fds'

main()

Running the above code:

    python ulimit.py [-n number] [-t]
    default number = 50, while using 'real' fd-s for temporary files.
    When using the '-t' flag 'smart' temporary files are used.

    Output:

        $ python ulimit.py
        aantal te gebruiken fd's: 50
        tmp: add_fd
        aantal vrije gebruiken fd's: 970

        $ python ulimit.py -t
        aantal te gebruiken fd's: 50
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

        $ python ulimit.py -n 1000
        aantal te gebruiken fd's: 1000
        tmp: add_fd
        aantal vrije gebruiken fd's: 20

        $ python ulimit.py -n 1000 -t
        aantal te gebruiken fd's: 1000
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020
-------------------------------------------------------

Date: 2001-Feb-16 21:41
By: akuchling

Comment:
I assume you mean 64 file upload fields, right?  
Can you provide a small test program that triggers the problem?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131249&group_id=5470


From noreply@sourceforge.net  Sun Feb 18 22:15:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 14:15:18 -0800
Subject: [Python-bugs-list] [Bug #132817] test_ucn fails on OpenVMS - AssertionError
Message-ID: <E14Uc6w-0003wk-00@usw-sf-web1.sourceforge.net>

Bug #132817, was updated on 2001-Feb-17 05:54
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Submitted by: zessin_5
Assigned to : effbot
Summary: test_ucn fails on OpenVMS - AssertionError

Details: test_ucn

On OpenVMS, this test fails with the following error message:

test test_ucn crashed -- exceptions.AssertionError: failed
 to raise an exception when given a bogus character name


How can I diagnose this?


Follow-Ups:

Date: 2001-Feb-18 14:15
By: effbot

Comment:
Okay, I just checked in a new version of DecodeUnicodeEscape (still not
100% happy with it, but it's better than before) /F
-------------------------------------------------------

Date: 2001-Feb-18 12:09
By: tim_one

Comment:
I just had in mind initializing chr to a known-bogus value and assert'ing
it doesn't still have that value when it's finally referenced, so that a
reoccurrence of this (or similar) bug won't pass by accident again.

I understand that the code was intended to work as you say, but better safe
than to trust that all future maintainers will figure that out when they're
hacking in the middle of the 200+ lines of code across which this
undocumented invariant is supposed to hold.  Goodness, the code even
initializes p, despite that it's set again within a mere dozen lines
<wink>.
-------------------------------------------------------

Date: 2001-Feb-18 11:35
By: effbot

Comment:
Tim, "getcode" is supposed to set the "chr" value if it returns non-zero. 
After Uwe's fix, this is exactly what it does.

But DecodeUnicodeEscape is rather messy; I've discovered a few other cases
where it can misbehave.  I'll do something about it asap. /F
-------------------------------------------------------

Date: 2001-Feb-18 08:34
By: tim_one

Comment:
/F, I'm re-opening this until it's understood.  It's clear that the test
"worked" by accident before, yes?  I stepped thru it ("N{blah}") in the
debugger on Windows, under the old code.  The reason it worked then is
that, in PyUnicode_DecodeUnicodeEscape, the stack vrbl "chr" remained
uninitialized all the way to label "store:", where a series of tests then
checked this stack trash against various ranges.  On Windows the trash
happened to be the too-large-for-Unicode 0x0063f9dc, so triggered a
different error by accident.  Presumably under OpenVMS, the trash passed
those tests by accident.

Perhaps it's impossible to ever test stack trash now, but I'd feel better
if the code covered its ass there anyway.  You?
-------------------------------------------------------

Date: 2001-Feb-18 03:46
By: effbot

Comment:
thanks for spotting the typo.  just wish I knew why
this didn't show up on any other platform...
-------------------------------------------------------

Date: 2001-Feb-17 14:37
By: zessin_5

Comment:
Here is the result from my debugging:

UNICODEOBJECT.C
if (!ucnhash_CAPI->getcode(start, endBrace-start, &chr)) {

calls:
UNICODEDATA.C:
getcode(const char* name, int namelen, Py_UCS4* code)
{

There are 4 'return's in getcode().
After I replace the 'return -1;' with 'return 0;'
I get the exceptions.
-------------------------------------------------------

Date: 2001-Feb-17 10:20
By: tim_one

Comment:
Assigned to /F.

zessin_5, look at test_ucn.py, if you want.  The error in question is
raised in only one place, verifying that

"\N{blah}"

raises UnicodeError when passed thru unicode-escape.  Don't know why it's
not on your platform.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132817&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 00:46:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 16:46:13 -0800
Subject: [Python-bugs-list] [Bug #133033] Build on a New Machine Needs Pre-existing Libs??
Message-ID: <E14UeSz-0002Fu-00@usw-sf-web2.sourceforge.net>

Bug #133033, was updated on 2001-Feb-18 16:46
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: Build on a New Machine Needs Pre-existing Libs??

Details: It seems that when one tries to build and install Python on a
machine that had no previous versions of Python on it, part of the build
and install procedure runs a Python program that imports several modules.
The problem is that at that point, no Python library or PYTHONHOME has yet
been defined and the script fails. As a result, it seems necessary to first
install a precompiled binary version of Python before one can successfully
build and install Python from scratch.
...Bob    ryodlowski@pirus.com


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133033&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 04:02:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 20:02:36 -0800
Subject: [Python-bugs-list] [Bug #133041] ftplib close() shouldn't delete self.sock, self.file
Message-ID: <E14UhX2-0003li-00@usw-sf-web2.sourceforge.net>

Bug #133041, was updated on 2001-Feb-18 20:02
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: ftplib close() shouldn't delete self.sock, self.file

Details: In FTP.__init__ it does:
		self.sock = None
		self.file = None

But in FTP.__close__ it does:
	def close(self):
		'''Close the connection without assuming anything about it.'''
		self.file.close()
		self.sock.close()
		del self.file, self.sock

This seems wrong -- instead of "del self.file, self.sock", shouldn't it be
"self.file = self.sock = None"?

This is a bug if only for the reason that it can lead to errors being
thrown that are not in ftplib.all_errors (i.e. an AttributeError).


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133041&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 04:37:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 20:37:30 -0800
Subject: [Python-bugs-list] [Bug #132879] 2.1a2 minor bug in "make clean" target
Message-ID: <E14Ui4o-0000ep-00@usw-sf-web3.sourceforge.net>

Bug #132879, was updated on 2001-Feb-17 16:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 minor bug in "make clean" target

Details: 2..1a2 from CVS of Feb 18 has the following as part of the "make
clean" target:
if test -f build; then find build -name '*.o' -exec rm -f {} ';' ; fi
"build" is a directory, so test should be "test -d build". I'll submit a
patch for this.

Follow-Ups:

Date: 2001-Feb-18 20:37
By: nascheme

Comment:
Fixed by using "find . -name '*.o' ...".
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132879&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 04:48:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 20:48:49 -0800
Subject: [Python-bugs-list] [Bug #132783] 2.1a2 fails to build extensions under Solaris 8 with gcc
Message-ID: <E14UiFl-0000jt-00@usw-sf-web3.sourceforge.net>

Bug #132783, was updated on 2001-Feb-16 16:42
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 fails to build extensions under Solaris 8 with gcc 

Details: Platform: SunOS asafoetida 5.8 Generic_108528-04 sun4u sparc
SUNW,Ultra-60
Compiler: gcc version 2.95.2 19991024 (release)
2.1a2 from CVS of Feb 16

"make" builds the bootstrap python successfully, but fails to build any
extensions due to lack of "-fPIC" compiler option. Putting this option in
by hand allows the extensions to build. A typical error message is:

building 'struct' extension
creating build
creating build/temp.solaris-2.8-sun4u-2.1
gcc -g -O2 -Wall -Wstrict-prototypes -I.
-I/export/home0/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include 
-c /export/home0/mark/src/python/CVS/python/dist/src/Modules/structmodule.c
-o build/temp.solaris-2.8-sun4u-2.1/structmodule.o
creating build/lib.solaris-2.8-sun4u-2.1
gcc -shared build/temp.solaris-2.8-sun4u-2.1/structmodule.o
-L/usr/local/lib -o 
build/lib.solaris-2.8-sun4u-2.1/struct.so
WARNING: building of extension "struct" failed: command 'gcc' failed with
exit status 1

Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x1204     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
<unknown>                           0x1208     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
<unknown>                           0x120c     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
<unknown>                           0x1210     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
.
<lots more elided>
.
PyErr_ExceptionMatches              0xc78      
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
Py_InitModule4                      0x1c48     
build/temp.solaris-2.8-sun4u-2.1
/structmodule.o
ld: fatal: relocations remain against allocatable but non-writable
sections
collect2: ld returned 1 exit status


Follow-Ups:

Date: 2001-Feb-18 20:48
By: nascheme

Comment:
Checked in patch 103865.
-------------------------------------------------------

Date: 2001-Feb-17 16:56
By: mfavas

Comment:
I've submitted a patch to configure.in to fix this bug - patch number
103865. 
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132783&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 07:12:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 23:12:55 -0800
Subject: [Python-bugs-list] [Bug #133050] Python-2.1a2 tests failed on NetBSD 1.5 i386
Message-ID: <E14UkVD-00069o-00@usw-sf-web2.sourceforge.net>

Bug #133050, was updated on 2001-Feb-18 23:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: aandersen
Assigned to : nobody
Summary: Python-2.1a2 tests failed on NetBSD 1.5 i386

Details: Experiences from compiling and installing Python-2.1a2 on a NetBSD
1.5
i386 machine with the pth 1.3.7 thread implementation (thread library
installed as a NetBSD package and located in the /usr/pkg directory):

Configure done with the following command:

  CFLAGS=`pthread-config --cflags` \
  LDFLAGS=`pthread-config --ldflags` \
  LIBS=`pthread-config --libs` \
  ./configure 

Added thread information to CFLAGS and LDFLAGS in Makefile:

  CFLAGS=   $(OPT) -I/usr/pkg/include -I. -I$(srcdir)/Include $(DEFS)
  LDFLAGS=  -L/usr/pkg/lib

Build Python-2.1a2 with the `make' command.  Run tests (make test)
with the following results:

  Skipped: al, bsddb, cd, cl, dl, gdbm, gl, imgfile, linuxaudiodev,
  minidom, nis, pyexpat, sax, sunaudiodev, sundry, winreg, winsound

  Failed: fork1, largefile, mailbox, ucn

I noticed the following strange problems: `make test' hangs forever on
test_thread, but test_thread works OK done separately.  test_pty hangs
forever done separately, but works OK during `make test'.

Results from failed tests:

  $ ./python Lib/test/test_fork1.py
  Traceback (most recent call last):
    File "Lib/test/test_fork1.py", line 72, in ?
      main()
    File "Lib/test/test_fork1.py", line 47, in main
      verify(a == range(NUM_THREADS))
    File "./Lib/test/test_support.py", line 81, in verify
      raise TestFailed(reason)
  test_support.TestFailed: test failed

  $ ./python Lib/test/test_largefile.py
  Traceback (most recent call last):
    File "Lib/test/test_largefile.py", line 18, in ?
      f.seek(2147483649L)
  IOError: [Errno 22] Invalid argument

  $ ./python Lib/test/test_mailbox.py  
  Traceback (most recent call last):
    File "Lib/test/test_mailbox.py", line 23, in ?
      try: os.rmdir(newdir)
  OSError: [Errno 20] Not a directory: '@test/new'

  $ ./python Lib/test/test_mailbox.py 
  ...
  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


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133050&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 07:17:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 23:17:59 -0800
Subject: [Python-bugs-list] [Bug #132786] 2.1a2 "make test" failures under Solaris 8
Message-ID: <E14Uka7-0001zv-00@usw-sf-web1.sourceforge.net>

Bug #132786, was updated on 2001-Feb-16 16:58
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : nobody
Summary: 2.1a2 "make test" failures under Solaris 8

Details: 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



Follow-Ups:

Date: 2001-Feb-18 23:17
By: mfavas

Comment:
The test_ucn bug has been fixed by /F, after a subsequent report of failure
on OpenVMS (bug id 132817, Feb 17).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132786&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 07:19:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 23:19:00 -0800
Subject: [Python-bugs-list] [Bug #133050] Python-2.1a2 tests failed on NetBSD 1.5 i386
Message-ID: <E14Ukb6-00020T-00@usw-sf-web1.sourceforge.net>

Bug #133050, was updated on 2001-Feb-18 23:12
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: aandersen
Assigned to : nobody
Summary: Python-2.1a2 tests failed on NetBSD 1.5 i386

Details: Experiences from compiling and installing Python-2.1a2 on a NetBSD
1.5
i386 machine with the pth 1.3.7 thread implementation (thread library
installed as a NetBSD package and located in the /usr/pkg directory):

Configure done with the following command:

  CFLAGS=`pthread-config --cflags` \
  LDFLAGS=`pthread-config --ldflags` \
  LIBS=`pthread-config --libs` \
  ./configure 

Added thread information to CFLAGS and LDFLAGS in Makefile:

  CFLAGS=   $(OPT) -I/usr/pkg/include -I. -I$(srcdir)/Include $(DEFS)
  LDFLAGS=  -L/usr/pkg/lib

Build Python-2.1a2 with the `make' command.  Run tests (make test)
with the following results:

  Skipped: al, bsddb, cd, cl, dl, gdbm, gl, imgfile, linuxaudiodev,
  minidom, nis, pyexpat, sax, sunaudiodev, sundry, winreg, winsound

  Failed: fork1, largefile, mailbox, ucn

I noticed the following strange problems: `make test' hangs forever on
test_thread, but test_thread works OK done separately.  test_pty hangs
forever done separately, but works OK during `make test'.

Results from failed tests:

  $ ./python Lib/test/test_fork1.py
  Traceback (most recent call last):
    File "Lib/test/test_fork1.py", line 72, in ?
      main()
    File "Lib/test/test_fork1.py", line 47, in main
      verify(a == range(NUM_THREADS))
    File "./Lib/test/test_support.py", line 81, in verify
      raise TestFailed(reason)
  test_support.TestFailed: test failed

  $ ./python Lib/test/test_largefile.py
  Traceback (most recent call last):
    File "Lib/test/test_largefile.py", line 18, in ?
      f.seek(2147483649L)
  IOError: [Errno 22] Invalid argument

  $ ./python Lib/test/test_mailbox.py  
  Traceback (most recent call last):
    File "Lib/test/test_mailbox.py", line 23, in ?
      try: os.rmdir(newdir)
  OSError: [Errno 20] Not a directory: '@test/new'

  $ ./python Lib/test/test_mailbox.py 
  ...
  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


Follow-Ups:

Date: 2001-Feb-18 23:18
By: aandersen

Comment:
The last test was test_ucn and not test_mailbox.  Sorry
about the cut and paste error.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133050&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 07:20:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 23:20:41 -0800
Subject: [Python-bugs-list] [Bug #132010] urllib and httplib fails to open url
Message-ID: <E14Ukcj-00021l-00@usw-sf-web1.sourceforge.net>

Bug #132010, was updated on 2001-Feb-12 08:51
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 5
Submitted by: apederse
Assigned to : gstein
Summary: urllib and httplib fails to open url

Details: urllib and httplib fails to open the URL:
"http://www.redherring.com/". By examining network traffic a request and
response from server is taking place but python simply hangs with an
"connection reset by peer" when it tries to open this particular URL.
Fredrik Lundh had a work-around to this problem while using httplib by
doing an explicit socket.close(), however I believe that more people should
look into the problem and hopefully a fix could be available for both
urllib and httplib. The problem has been reported to fail under both
version 1.5.2 and 2.0, however I have only tested it under ver.1.5.2

for more details do also take a look at:
http://x61.deja.com/%5BST_rn=ps%5D/viewthread.xp?AN=725477609&search=thread&svcclass=dnyr&ST=PS&CONTEXT=981992343.458686528&HIT_CONTEXT=981992343.458686528&HIT_NUM=0&recnum=%3c95th67$36j$1@nnrp1.deja.com%3e%231/1&group=comp.lang.python&frpage=viewthread.xp&back=clarinet


Follow-Ups:

Date: 2001-Feb-18 23:20
By: gstein

Comment:
The TCP stack at www.redherring.com is flat out broken. There is nothing we
can do to fix this, short of a redesign of the httplib interface.

Essentially, if the entire HTTP request does not arrive in a single packet,
then redherring falls over. In fact, it won't even send a TCP ACK packet
for the first packet in the request. If the *whole* request arrives in one
packet, then it properly ACKs it and delivers the response.

Short of buffering up the request in the HTTPConnection object or
redesigning the API, there isn't much we can do to fix this bug. I also
think it is bad precedent to compensate for a flat-out busted TCP stack.
Workaround web server problems? maybe. But TCP stacks? Feh.

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

Date: 2001-Feb-18 03:20
By: effbot

Comment:
reassigned to greg, who wrote the 2.0 code.

summary: the redherring server requires an explicit
shutdown before it starts returning data.  From what
I can tell, httplib is doing everything by the book,
so it's probably a broken/braindead server.  But it
does appear to work with most browsers...

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

Date: 2001-Feb-13 02:15
By: tim_one

Comment:
Assigned to /F since he's already looked at this.  So what's up with
redherring.com?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132010&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 07:32:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 18 Feb 2001 23:32:27 -0800
Subject: [Python-bugs-list] [Bug #131249] cgi.py opens too many (temporary) files
Message-ID: <E14Uko7-0002u1-00@usw-sf-web3.sourceforge.net>

Bug #131249, was updated on 2001-Feb-06 04:59
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: stadt
Assigned to : akuchling
Summary: cgi.py opens too many (temporary) files

Details: cgi.FieldStorage() is used to get the contents of a webform. It
turns out that
for each <input> line, a new temporary file is opened. This causes the
script
that is using cgi.FieldStorage() to reach the webserver's limit of number
of
opened files, as described by 'ulimit -n'. The standard value for Solaris
systems
seems to be 64, so webforms with that many <input> fields cannot be dealt
with.

A solution would seem to use the same temporary filename, since only a
maxmimum one file is (temporarily) used at the same time. I did an "ls|wc
-l"
while the script was running, which showed only zeroes and ones.

(I'm using Python for CyberChair, an online paper submission and reviewing
system.
The webform under discussion has one input field for each reviewer, stating
the
papers he or she is supposed to be reviewing. One conference that is using
CyberChair
has almost 140 reviewers. Their system's open file limit is 64. Using the
same data on
a system with an open file limit of 260 _is_ able to deal with this.)

Follow-Ups:

Date: 2001-Feb-18 23:32
By: kbk

Comment:
In the particular HTML form referenced it appears that a workaround might
be to eliminate the enctype attribute in the <form> tag and take the
application/x-www-form-urlencoded default since no files are being
uploaded. 

When make_file creates the temporary files they are immediately unlinked.
There is probably a brief period before the unlink is finalized during
which the ls process might see a file; that would account for the output of
ls | wc. It appears that the current cgi.py implementation leaves all the
(hundreds of) files open until the cgi process releases the FieldStorage
object or exits. 

My first thought was, if the filename recovered from the header is None
have make_file create a StringIO object instead of a temp file. That way a
temp file is only created when a file is uploaded. This is not inconsistent
with the cgi.py docs.

Unfortunately, RFC2388 4.4 states that a filename is not required to be
sent, so it looks like your solution based on the size of the data received
is the correct one. Below 1K you could copy the temp file contents to a
StringIO and assign it to self.file, then explicitly close the temp file
via its descriptor. 

If only I understood the module better ::-(( and had a way of tunnel
testing it I might have had the temerity to offer a patch. (I'm away for a
couple of weeks starting tomorrow.)
-------------------------------------------------------

Date: 2001-Feb-18 14:08
By: akuchling

Comment:
Ah, I see; the traceback makes this much clearer.  When you're uploading a
file, everything in the form is sent as 
a MIME document in the body; every field is accompanied by 
a boundary separator and Content-Disposition header.
In multipart mode, cgi.py copies each field into a temporary file.  

The first idea I had was to only use tempfiles for the actual upload field;
unfortunately, that doesn't help because the upload field isn't special,
and cgi.py has no way to know which it is ahead of time.

Possible second approach: measure the size of the resulting file; if it's
less than some threshold (1K? 10K?), read its contents into memory and
close the tempfile.  This means only the largest fields will require that a
file descriptor be kept open.  I'll explore this more after beta1.



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

Date: 2001-Feb-17 18:37
By: stadt

Comment:
I do *not* mean file upload fields. I stumbled upon this with a webform
that
contains 141 'simple' input fields like the form you can see here (which
'only'
contains 31 of those input fields):

http://www.cyberchair.org/cgi-cyb/genAssignPageReviewerPapers.py

(use chair/chair to login)

When the maximum number of file descriptors used per process was
increased
to 160 (by the sysadmins), the problem did not occur anymore, and the
webform
could be processed.

This was the error message I got: 

Traceback (most recent call last):
  File
"/usr/local/etc/httpd/DocumentRoot/ICML2001/cgi-bin/submitAssignRP.py",
line 144, in main
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 504, in
__init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 593, in
read_multi
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 506, in
__init__
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 603, in
read_single
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 623, in
read_lines
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/cgi.py", line 713, in
make_file
  File "/opt/python/2.0/sparc-sunos5.6/lib/python2.0/tempfile.py", line
144, in TemporaryFile
OSError: [Errno 24] Too many open files:
'/home/yara/brodley/icml2001/tmp/@26048.61'

I understand why you assume that it would concern *file* uploads, but this
is
not the case. As I reported before, it turns out that for each 'simple'
<input> field
a temporary file is used in to transfer the contents to the script that
uses the
cgi.FieldStorage() method, even if no files are being uploaded. The problem
is not
that too many files are open at the same time (which is 1 at most). It is
the *amount*
of files that is causing the troubles. If the same temporary file would be
used, this
problem would probably not have happened. 

My colleague Fred Gansevles wrote a possible solution, but mentioned that
this
might introduce the need for protection against a 'symlink attack'
(whatever
that may be). This solution(?) concentrates on the open file descriptor's
problem,
while Fred suggests a redesign of FieldStorage() would probably be
better.

import os, tempfile
AANTAL = 50

class TemporaryFile:
    def __init__(self):
        self.name = tempfile.mktemp("")
        open(self.name, 'w').close()
        self.offset = 0
    
    def seek(self, offset):
        self.offset = offset
    
    def read(self):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        data = fd.read()
        self.offset = fd.tell()
        fd.close()
        return data
    
    def write(self, data):
        fd = open(self.name, 'w+b', -1)
        fd.seek(self.offset)
        fd.write(data)
        self.offset = fd.tell()
        fd.close()

    def __del__(self):
        os.unlink(self.name)

def add_fd(l, n) :
    map(lambda x,l=l: l.append(open('/dev/null')), range(n))

def add_tmp(l, n) :
    map(lambda x,l=l: l.append(TemporaryFile()), range(n))

def main ():
    import getopt, sys
    try:
        import resource
        soft, hard = resource.getrlimit (resource.RLIMIT_NOFILE)
        resource.setrlimit (resource.RLIMIT_NOFILE, (hard, hard))
    except ImportError:
        soft, hard = 64, 1024
    opts, args = getopt.getopt(sys.argv[1:], 'n:t')
    aantal = AANTAL
    tmp = add_fd
    for o, a in opts:
        if o == '-n':
            aantal = int(a)
        elif o == '-t':
            tmp = add_tmp
    print "aantal te gebruiken fd's:", aantal   #dutch; English: 'number of
fds to be used'
    print 'tmp:', tmp.func_name
    tmp_files = []
    files=[]
    tmp(tmp_files, aantal)
    try:
        add_fd(files,hard)
    except IOError:
        pass
    print "aantal vrije gebruiken fd's:", len(files)  #enlish: 'number of
free fds'

main()

Running the above code:

    python ulimit.py [-n number] [-t]
    default number = 50, while using 'real' fd-s for temporary files.
    When using the '-t' flag 'smart' temporary files are used.

    Output:

        $ python ulimit.py
        aantal te gebruiken fd's: 50
        tmp: add_fd
        aantal vrije gebruiken fd's: 970

        $ python ulimit.py -t
        aantal te gebruiken fd's: 50
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020

        $ python ulimit.py -n 1000
        aantal te gebruiken fd's: 1000
        tmp: add_fd
        aantal vrije gebruiken fd's: 20

        $ python ulimit.py -n 1000 -t
        aantal te gebruiken fd's: 1000
        tmp: add_tmp
        aantal vrije gebruiken fd's: 1020
-------------------------------------------------------

Date: 2001-Feb-16 21:41
By: akuchling

Comment:
I assume you mean 64 file upload fields, right?  
Can you provide a small test program that triggers the problem?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131249&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 15:17:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 07:17:38 -0800
Subject: [Python-bugs-list] [Bug #133084] nis.match('username', 'aliases') does not work under Linux
Message-ID: <E14Us4I-00016z-00@usw-sf-web2.sourceforge.net>

Bug #133084, was updated on 2001-Feb-19 07:17
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: nis.match('username', 'aliases') does not work under Linux

Details: The exception 'nis.error: No such key in map' is thrown
when issuing

>>> nis.match('username', 'aliases')

under SuSE-Linux 6.4 and 7.0 with both Python 2.0 and 
Python 2.1a2, even if 'username' is valid and 

$ ypmatch username aliases

works.

Fix: Apply the following patch to Modules/nismodule.c

--- nismodule.c.sv      Mon Feb 19 16:12:10 2001
+++ nismodule.c Mon Feb 19 16:15:28 2001
@@ -43,7 +43,7 @@
        {"hosts",       "hosts.byname",         0},
        {"protocols",   "protocols.bynumber",   0},
        {"services",    "services.byname",      0},
-       {"aliases",     "mail.aliases",         1}, /* created with
'makedbm -a' */
+       {"aliases",     "mail.aliases",         0}, /* created with
'makedbm -a' */
        {"ethers",      "ethers.byname",        0},
        {0L,            0L,                     0}
 };


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133084&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 15:33:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 07:33:44 -0800
Subject: [Python-bugs-list] [Bug #132510] Fatal error on x+1=1
Message-ID: <E14UsJs-0006ff-00@usw-sf-web1.sourceforge.net>

Bug #132510, was updated on 2001-Feb-15 05:33
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 8
Submitted by: gvanrossum
Assigned to : jhylton
Summary: Fatal error on x+1=1

Details: The statement x+1=1 causes the code generator to dump some
internal data structures and issue a fatal error:
too many children in default case.  The dump says:
300: (null)
  301: (null)
    302: (null)
      303: (null)
        304: (null)
          1: x
  14: +
  301: (null)
    302: (null)
      303: (null)
        304: (null)
          2: 1



Follow-Ups:

Date: 2001-Feb-19 07:33
By: jhylton

Comment:
Fixed in rev. 2.166 of compile.c

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132510&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 15:51:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 07:51:25 -0800
Subject: [Python-bugs-list] [Bug #132820] Nested scopes have problems in -O mode
Message-ID: <E14Usaz-0006Kw-00@usw-sf-web3.sourceforge.net>

Bug #132820, was updated on 2001-Feb-17 06:12
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Submitted by: lemburg
Assigned to : jhylton
Summary: Nested scopes have problems in -O mode

Details: I've just gotten a report by a beta tester of my eGenix
mx-Extensions which sounds like a bug in the compiler.

Here's the URL to the distutils installer which reproduces the
problem when byte-code compiling the file
mx/Tools/mxTools/test.py 

http://www.lemburg.com/python/egenix-mx-base-1.0.0.zip

As it turns out, the compiler error only occurrs when you compile
test.py in optimized mode:

...
byte-compiling
/usr/local/lib/python2.1/site-packages/mx/Tools/mxTools/test.py to
test.pyc
...
byte-compiling
/usr/local/lib/python2.1/site-packages/mx/Tools/mxTools/test.py to
test.pyo
Fatal Python error: unknown scope for a in testkw(2) in
/usr/local/lib/python2.1/site-packages/mx/Tools/mxTools/test.py



Follow-Ups:

Date: 2001-Feb-19 07:51
By: jhylton

Comment:
Fixed by rev 2.167 of compile.c

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

Date: 2001-Feb-17 06:13
By: lemburg

Comment:
Assigning this to Jeremy, since he knows this code best.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132820&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 16:04:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 08:04:14 -0800
Subject: [Python-bugs-list] [Bug #131825] doctest.py needs docs
Message-ID: <E14UsnO-0006Qv-00@usw-sf-web3.sourceforge.net>

Bug #131825, was updated on 2001-Feb-10 01:03
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Submitted by: tim_one
Assigned to : fdrake
Summary: doctest.py needs docs

Details: I need to write something up for Fred.  The doctest docstrings are
too much info -- need a much quicker intro for the Library Manual, and
point to the docstrings for unusual cases (I personally almost never use
*any* of the fancy stuff!).


Follow-Ups:

Date: 2001-Feb-19 08:04
By: fdrake

Comment:
Tim & Moshe have fixed this already; docs are in Doc/lib/libdoctest.tex.
-------------------------------------------------------

Date: 2001-Feb-16 22:04
By: tim_one

Comment:
Moshe did LaTeXification, and I just checked in his patch (which is now
closed).
-------------------------------------------------------

Date: 2001-Feb-14 22:37
By: tim_one

Comment:
Doc, doc!  Who's there?  doctest docs.

https://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103808&group_id=5470

Plain ASCII.  See patch comments for other blather.

Assigned to Fred.  But bet he'd like it if someone else with LaTeXification
powers did this.  I'm not mentioning Moshe by name, though.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131825&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 16:31:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 08:31:16 -0800
Subject: [Python-bugs-list] [Bug #131824] New std library difflib.py needs docs
Message-ID: <E14UtDY-0007Fn-00@usw-sf-web1.sourceforge.net>

Bug #131824, was updated on 2001-Feb-10 00:07
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 6
Submitted by: tim_one
Assigned to : fdrake
Summary: New std library difflib.py needs docs

Details: LaTeXification of the module docstring should be all it requires. 
Unsure where to put it, but "Miscellaneous Services" fits better than most.

Follow-Ups:

Date: 2001-Feb-19 08:31
By: fdrake

Comment:
Documentation added based on module docstrings.  Checked in as
Doc/lib/libdifflib.tex.

Tim, do you have a reference to the R-O algorithm?  Is your algorithm
published anywhere?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131824&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 17:03:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 09:03:36 -0800
Subject: [Python-bugs-list] [Bug #133096] Fatal python error in com_make_closure()
Message-ID: <E14Utiq-0007ZV-00@usw-sf-web1.sourceforge.net>

Bug #133096, was updated on 2001-Feb-19 09:03
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: glchapman
Assigned to : nobody
Summary: Fatal python error in com_make_closure()

Details: This construct causes python (2.1 alpha 2) to crash:

>>> def test(n):
...     return lambda fact: fact(fact, long(n))
...
lookup 'n' in test 1 -1
Fatal Python error: com_make_closure()

To try to help narrow it down, the following works with no problem:

>>> def test(n):
...     return lambda fact: fact(fact, n)

So it appears that adding the call to the long function is breaking
something.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133096&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 17:05:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 09:05:48 -0800
Subject: [Python-bugs-list] [Bug #133096] Fatal python error in com_make_closure()
Message-ID: <E14Utky-0007b2-00@usw-sf-web1.sourceforge.net>

Bug #133096, was updated on 2001-Feb-19 09:03
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: glchapman
Assigned to : nobody
Summary: Fatal python error in com_make_closure()

Details: This construct causes python (2.1 alpha 2) to crash:

>>> def test(n):
...     return lambda fact: fact(fact, long(n))
...
lookup 'n' in test 1 -1
Fatal Python error: com_make_closure()

To try to help narrow it down, the following works with no problem:

>>> def test(n):
...     return lambda fact: fact(fact, n)

So it appears that adding the call to the long function is breaking
something.


Follow-Ups:

Date: 2001-Feb-19 09:05
By: glchapman

Comment:
I probably should have added that I'm using the Win32 compiled version
downloaded from SourceForge (operating system is Windows 2000).

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133096&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 17:18:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 09:18:36 -0800
Subject: [Python-bugs-list] [Bug #133096] Fatal python error in com_make_closure()
Message-ID: <E14UtxM-0006y0-00@usw-sf-web3.sourceforge.net>

Bug #133096, was updated on 2001-Feb-19 09:03
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: glchapman
Assigned to : nobody
Summary: Fatal python error in com_make_closure()

Details: This construct causes python (2.1 alpha 2) to crash:

>>> def test(n):
...     return lambda fact: fact(fact, long(n))
...
lookup 'n' in test 1 -1
Fatal Python error: com_make_closure()

To try to help narrow it down, the following works with no problem:

>>> def test(n):
...     return lambda fact: fact(fact, n)

So it appears that adding the call to the long function is breaking
something.


Follow-Ups:

Date: 2001-Feb-19 09:18
By: mwh

Comment:
Nah, it crashes on linux too.

It doesn't crash if you change almost anything about the test-case, so it's
probably some bizarre kind of dictionary traversal bug again.
-------------------------------------------------------

Date: 2001-Feb-19 09:05
By: glchapman

Comment:
I probably should have added that I'm using the Win32 compiled version
downloaded from SourceForge (operating system is Windows 2000).

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133096&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 18:34:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 10:34:17 -0800
Subject: [Python-bugs-list] [Bug #133096] Fatal python error in com_make_closure()
Message-ID: <E14Uv8b-0002bc-00@usw-sf-web2.sourceforge.net>

Bug #133096, was updated on 2001-Feb-19 09:03
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: glchapman
Assigned to : nobody
Summary: Fatal python error in com_make_closure()

Details: This construct causes python (2.1 alpha 2) to crash:

>>> def test(n):
...     return lambda fact: fact(fact, long(n))
...
lookup 'n' in test 1 -1
Fatal Python error: com_make_closure()

To try to help narrow it down, the following works with no problem:

>>> def test(n):
...     return lambda fact: fact(fact, n)

So it appears that adding the call to the long function is breaking
something.


Follow-Ups:

Date: 2001-Feb-19 10:34
By: mwh

Comment:
OTOH, I've just rebuilt and it seems to have gone away.

A bug of this kind was fixed in revision 2.163 of compile.c (on
2001/02/12)- can you try after that?
-------------------------------------------------------

Date: 2001-Feb-19 09:18
By: mwh

Comment:
Nah, it crashes on linux too.

It doesn't crash if you change almost anything about the test-case, so it's
probably some bizarre kind of dictionary traversal bug again.
-------------------------------------------------------

Date: 2001-Feb-19 09:05
By: glchapman

Comment:
I probably should have added that I'm using the Win32 compiled version
downloaded from SourceForge (operating system is Windows 2000).

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133096&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 21:27:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 13:27:52 -0800
Subject: [Python-bugs-list] [Bug #133096] Fatal python error in com_make_closure()
Message-ID: <E14Uxqa-0001pl-00@usw-sf-web1.sourceforge.net>

Bug #133096, was updated on 2001-Feb-19 09:03
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: glchapman
Assigned to : jhylton
Summary: Fatal python error in com_make_closure()

Details: This construct causes python (2.1 alpha 2) to crash:

>>> def test(n):
...     return lambda fact: fact(fact, long(n))
...
lookup 'n' in test 1 -1
Fatal Python error: com_make_closure()

To try to help narrow it down, the following works with no problem:

>>> def test(n):
...     return lambda fact: fact(fact, n)

So it appears that adding the call to the long function is breaking
something.


Follow-Ups:

Date: 2001-Feb-19 13:27
By: fdrake

Comment:
Assigned to Mr. Compiler.
-------------------------------------------------------

Date: 2001-Feb-19 10:34
By: mwh

Comment:
OTOH, I've just rebuilt and it seems to have gone away.

A bug of this kind was fixed in revision 2.163 of compile.c (on
2001/02/12)- can you try after that?
-------------------------------------------------------

Date: 2001-Feb-19 09:18
By: mwh

Comment:
Nah, it crashes on linux too.

It doesn't crash if you change almost anything about the test-case, so it's
probably some bizarre kind of dictionary traversal bug again.
-------------------------------------------------------

Date: 2001-Feb-19 09:05
By: glchapman

Comment:
I probably should have added that I'm using the Win32 compiled version
downloaded from SourceForge (operating system is Windows 2000).

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133096&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 21:30:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 13:30:11 -0800
Subject: [Python-bugs-list] [Bug #132409] setup.py does not look in the right place for xmlparse.h
Message-ID: <E14Uxsp-0001rW-00@usw-sf-web1.sourceforge.net>

Bug #132409, was updated on 2001-Feb-14 14:16
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Invalid
Bug Group: Not a Bug
Priority: 5
Submitted by: ajseward
Assigned to : nobody
Summary: setup.py does not look in the right place for xmlparse.h

Details: Modules/pyexpat.c includes "expat/xmlparse.h" so setup.py should
also look for "expat/xmlparse.h".  Currently pyexpat will not build if
there is not a file named xmlparse.h in the standard include path.

See patch #103804 for a fix


Follow-Ups:

Date: 2001-Feb-19 13:30
By: fdrake

Comment:
Closed since this was a conflict with some outside patch and does not
reflect an error in the code as found in Python.
-------------------------------------------------------

Date: 2001-Feb-14 17:22
By: ajseward

Comment:
Sorry, this was caused by another patch that I had not looked at closely
enough.  There is no problem in the CVS source. 
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132409&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 21:33:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 13:33:18 -0800
Subject: [Python-bugs-list] [Bug #133084] nis.match('username', 'aliases') does not work under Linux
Message-ID: <E14Uxvq-0001t3-00@usw-sf-web1.sourceforge.net>

Bug #133084, was updated on 2001-Feb-19 07:17
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: nis.match('username', 'aliases') does not work under Linux

Details: The exception 'nis.error: No such key in map' is thrown
when issuing

>>> nis.match('username', 'aliases')

under SuSE-Linux 6.4 and 7.0 with both Python 2.0 and 
Python 2.1a2, even if 'username' is valid and 

$ ypmatch username aliases

works.

Fix: Apply the following patch to Modules/nismodule.c

--- nismodule.c.sv      Mon Feb 19 16:12:10 2001
+++ nismodule.c Mon Feb 19 16:15:28 2001
@@ -43,7 +43,7 @@
        {"hosts",       "hosts.byname",         0},
        {"protocols",   "protocols.bynumber",   0},
        {"services",    "services.byname",      0},
-       {"aliases",     "mail.aliases",         1}, /* created with
'makedbm -a' */
+       {"aliases",     "mail.aliases",         0}, /* created with
'makedbm -a' */
        {"ethers",      "ethers.byname",        0},
        {0L,            0L,                     0}
 };


Follow-Ups:

Date: 2001-Feb-19 13:33
By: fdrake

Comment:
Can anyone confirm this bug for other platforms?  How about the fix?  I
don't have any access a network that uses NIS these days.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133084&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 21:42:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 13:42:07 -0800
Subject: [Python-bugs-list] [Bug #132913] ConfigParser set() does not xform option
Message-ID: <E14Uy4N-0001yg-00@usw-sf-web1.sourceforge.net>

Bug #132913, was updated on 2001-Feb-17 21:45
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : fdrake
Summary: ConfigParser set() does not xform option

Details: ConfigParser's set(section,option,value) does not optionxform the
option when adding it to the section.  This is not consistent with what
happens from read().

Fix: add option=self.optionxform(option) at beginning of set()


Follow-Ups:

Date: 2001-Feb-19 13:42
By: fdrake

Comment:
has_option(), set(), and remove_option() all exhibit this issue.  I'll
check in the fix once I've written some test cases that deal with this.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132913&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 21:44:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 13:44:09 -0800
Subject: [Python-bugs-list] [Bug #132911] ConfigParser's has_option() is case-sensitive
Message-ID: <E14Uy6L-0001za-00@usw-sf-web1.sourceforge.net>

Bug #132911, was updated on 2001-Feb-17 21:38
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: ConfigParser's has_option() is case-sensitive

Details: First, there are two methods named has_option() in ConfigParser.

Second, in both cases has_option() is case sensitive.
Fix: add option = self.optionxform(option) at the beginning of the
method.



Follow-Ups:

Date: 2001-Feb-19 13:44
By: fdrake

Comment:
So, this was already reported.  I'll toss this one as a duplicate since
I've noted the problem in the report for the set() method.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132911&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 21:49:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 13:49:26 -0800
Subject: [Python-bugs-list] [Bug #133033] Build on a New Machine Needs Pre-existing Libs??
Message-ID: <E14UyBS-000233-00@usw-sf-web1.sourceforge.net>

Bug #133033, was updated on 2001-Feb-18 16:46
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : akuchling
Summary: Build on a New Machine Needs Pre-existing Libs??

Details: It seems that when one tries to build and install Python on a
machine that had no previous versions of Python on it, part of the build
and install procedure runs a Python program that imports several modules.
The problem is that at that point, no Python library or PYTHONHOME has yet
been defined and the script fails. As a result, it seems necessary to first
install a precompiled binary version of Python before one can successfully
build and install Python from scratch.
...Bob    ryodlowski@pirus.com


Follow-Ups:

Date: 2001-Feb-19 13:49
By: fdrake

Comment:
Did you get an error from actually trying this?  The current Makefile
builds a minimal Python which it then uses to continue the build process.

If your report was "inspired" by an actual failure, please give the
specific configure command you used, your platform, and a copy of the error
message.

Assigned to Andrew since this approach was based on his efforts; feel free
to re-assign if appropriate.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133033&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 21:53:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 13:53:15 -0800
Subject: [Python-bugs-list] [Bug #133147] map,reduce,filter + exec won't run together
Message-ID: <E14UyF9-0000cl-00@usw-sf-web3.sourceforge.net>

Bug #133147, was updated on 2001-Feb-19 13:53
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mpmak
Assigned to : nobody
Summary: map,reduce,filter + exec won't run together

Details: 
With latest (CVS) version of python included example won't even compile.
I&#8217;ve get same effect with reduce and filer instead of map.

def demo(xyz):
	zyx = map(lambda x: str(x), xyz)
	g = {}
	l = {}
	exec codeObject in g, l


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133147&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 21:55:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 13:55:59 -0800
Subject: [Python-bugs-list] [Bug #132597] 2.1a2 compiler warnings on Compaq Tru64 Unix
Message-ID: <E14UyHn-00027i-00@usw-sf-web1.sourceforge.net>

Bug #132597, was updated on 2001-Feb-15 12:35
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: mfavas
Assigned to : akuchling
Summary: 2.1a2 compiler warnings on Compaq Tru64 Unix

Details: 2.1a2 from CVS of Feb 16 produces the following compiler warnings
on Tru64
Unix (uname -a: OSF1 gonzo.per.dem.csiro.au V4.0 1229 alpha, Compaq C
compiler, version: Compaq C V6.3-129 (dtk), Compiler Driver V6.3-126
(dtk)):

cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Python/ceval.o
Python/ceval.c
cc: Info: Python/ceval.c, line 327: Trailing comma found in enumerator
list. (trailcomma)
};


cc -O -Olimit 1500 -I. -I./Include -IInclude/ -I/usr/local/include -c
Modules/_cursesmodule.c -o build/temp.osf1-V4.0-alpha-2.1/_cursesmodule.o
cc: Warning: Modules/_cursesmodule.c, line 632: In this statement,
"derwin(...)" of type "int", is being converted to "pointer to struct
_win_st". (cvtdiftypes)
  win = derwin(self->win,nlines,ncols,begin_y,begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1287: In this statement,
"subpad(...)" of type "int", is being converted to "pointer to struct
_win_st". (cvtdiftypes)
    win = subpad(self->win, nlines, ncols, begin_y, begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1517: In this statement,
"termname(...)" of type "int", is being converted to "pointer to const
char". (cvtdiftypes)
NoArgReturnStringFunction(termname)

cc: Warning: Modules/_cursesmodule.c, line 1686: In this statement,
"getwin(...)" of type "int", is being converted to "pointer to struct
_win_st". (cvtdiftypes)
  win = getwin(PyFile_AsFile(temp));

cc: Warning: Modules/_cursesmodule.c, line 1954: In this statement,
"keyname(...)" of type "int", is being converted to "pointer to const
char". (cvtdiftypes)
  knp = keyname(ch);

cc: Warning: Modules/_cursesmodule.c, line 2245: In this statement,
"tigetstr(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
        capname = tigetstr( capname );

cc: Warning: Modules/_cursesmodule.c, line 2270: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt);

cc: Warning: Modules/_cursesmodule.c, line 2273: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1);

cc: Warning: Modules/_cursesmodule.c, line 2276: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2);

cc: Warning: Modules/_cursesmodule.c, line 2279: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3);

cc: Warning: Modules/_cursesmodule.c, line 2282: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4);

cc: Warning: Modules/_cursesmodule.c, line 2285: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5);

cc: Warning: Modules/_cursesmodule.c, line 2288: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6);

cc: Warning: Modules/_cursesmodule.c, line 2291: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7);

cc: Warning: Modules/_cursesmodule.c, line 2294: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8);

cc: Warning: Modules/_cursesmodule.c, line 2297: In this statement,
"tparm(...)" of type "int", is being converted to "pointer to char".
(cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8,i9);

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg1"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg2"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg1"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg2"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg1"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg2"
is fetched but not initialized.  And there may be other such fetches of
this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")






Follow-Ups:

Date: 2001-Feb-19 13:55
By: fdrake

Comment:
Looks like a different header may be needed to pick up the prototypes for
many of these.  Assigned to the curses module guy.
-------------------------------------------------------

Date: 2001-Feb-16 04:14
By: twouters

Comment:
The first warning is my mistake. I thought I fixed that in a more recent
version of my continue-inside-try patch, but apparently I didn't. Fixed in
revision 2.230 of Python/ceval.c

The warnings in Modules/_cursusmodule.c are most likely caused by undefined
functions, though why you don't see an error for those beats me. (undefined
functions default to int-returning functions, so that's probably why you
see those warnings.) 

The *other* warnings look damned legit, though, and the only reason they
aren't is because getmaxyx and co. are (on the BSDI and Linux boxes I have
acces to) defined as being macro calls, and in fact they *have* to be macro
calls (or non-standard C calls) or they can't work. I'm not a curses
expert, but I think an initialization is in place here (or just rewriting
the silly macros so they make *sense* :-)

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132597&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 21:59:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 13:59:04 -0800
Subject: [Python-bugs-list] [Bug #132633] modules not building on AIX 4.2.1
Message-ID: <E14UyKm-00029L-00@usw-sf-web1.sourceforge.net>

Bug #132633, was updated on 2001-Feb-15 15:32
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Closed
Resolution: Invalid
Bug Group: Platform-specific
Priority: 5
Submitted by: bcollar
Assigned to : nobody
Summary: modules not building on AIX 4.2.1

Details: Hello

ran:

CC=cc_r CFLAGS="-O2 -qmaxmem=6000" ./configure --without-gcc
--prefix=/development/utils and 
make CC=cc_r OPT="-O2 -qmaxmem=6000" on 2.1a2 code patched with 103679 and
two manual additions in the Makefile so ld_so_aix and makexp_aix are found
(these last two things were committed into CVS, but I forget the patch
numbers...).
Python itself builds fine, but the following occurs when building any
module:

building 'fpectl' extension
skipping /tmp/python/python/dist/src/Modules/fpectlmodule.c
(build/temp.aix-2-000310094C00-2.1/fpectlmodule.o up-to-date)
@BLDSHARED@ build/temp.aix-2-000310094C00-2.1/fpectlmodule.o
-L/usr/local/lib -o build/lib.aix-2-000310094C00-2.1/fpectl.so
unable to execute @BLDSHARED@: No such file or directory


Follow-Ups:

Date: 2001-Feb-19 13:59
By: fdrake

Comment:
Closed since the submittor says it was his fault.
-------------------------------------------------------

Date: 2001-Feb-15 15:52
By: bcollar

Comment:
aw crap, that was my fault, sorry! please disregard this bug
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132633&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 22:12:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 14:12:32 -0800
Subject: [Python-bugs-list] [Bug #133147] map,reduce,filter + exec won't run together
Message-ID: <E14UyXo-0002I3-00@usw-sf-web1.sourceforge.net>

Bug #133147, was updated on 2001-Feb-19 13:53
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mpmak
Assigned to : jhylton
Summary: map,reduce,filter + exec won't run together

Details: 
With latest (CVS) version of python included example won't even compile.
I&#8217;ve get same effect with reduce and filer instead of map.

def demo(xyz):
	zyx = map(lambda x: str(x), xyz)
	g = {}
	l = {}
	exec codeObject in g, l


Follow-Ups:

Date: 2001-Feb-19 14:12
By: fdrake

Comment:
Yes; assigned to Jeremy since he can explain it or label it a real bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133147&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 23:07:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 15:07:56 -0800
Subject: [Python-bugs-list] [Bug #132600] 2.1a2 tries to build bsddb without "-ldb"
Message-ID: <E14UzPQ-0004ck-00@usw-sf-web2.sourceforge.net>

Bug #132600, was updated on 2001-Feb-15 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : akuchling
Summary: 2.1a2 tries to build bsddb without "-ldb"

Details: Platform: Tru64 Unix, V4.0F, Compaq C compiler version: Compaq C
V6.3-129 (dtk) on Digital UNIX V4.0F  (Rev. 1229), Compiler Driver V6.3-126
(dtk)

"make" causes setup.py to generate the following compile/link lines for the
bsddb extension:

cc -O -Olimit 1500 -I.
-I/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include -c
/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/Modules/bsddbmodule.c
-o build/temp.osf1-V4.0-alpha-2.1/bsddbmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V4.0-alpha-2.1/bsddbmodule.o -L/usr/local/lib -o
build/lib.osf1-V4.0-alpha-2.1/bsddb.so

The lack of a "-ldb" in the ld command causes "make test" to skip the bsddb
test (and "import bsddb" to fail) due to unresolved symbols. Looking at the
code in setup.py, the "-ldb" is only included if "db_185.h" is found. If
"db.h" is found instead, no "-l" is appended to the link line. Compaq Tru64
comes standard with db (a Compaq-modified 1.85 version, I believe), with
/usr/include/db.h and /usr/lib/libdb.a and /usr/shlib/libdb.so. Manually
adding "-ldb" to the above link line allows test_bsddb to run and pass.

Follow-Ups:

Date: 2001-Feb-19 15:07
By: mfavas

Comment:
I've just submitted a patch to setup.py to fix this - patch ID 103886.
-------------------------------------------------------

Date: 2001-Feb-16 02:47
By: twouters

Comment:
This bug is connected to at least one other bsddb bug ("clash with BSD db
when building", #117464) and maybe more. I think the solution is to rip out
all the autoconf stuff and do all the detecting in setup.py. I'm not sure
how to do it, though, and I don't have time to learn distutils right now
:-)

Andrew, assigning this (as well as the other bug) to you, so you can
consider the distutils solution. I can give you a rundown on how it should
work: basically, it should check for /usr/include/db{3,2}/db_185.h,
/usr/include/db1/db.h, /usr/include/db_185.h and /usr/include/db.h in that
order, try to find out if the found db.h is indeed version 1 (if it doesn't
contain a DB_VERSION_MAJOR #define, or it's #defined as 1, it's version 1),
and then try to find out if dbopen() is in libc or not. This all can be
written in autoconf, if it's really necessary, though it would probably
create quite a mess in bsddbmodule.c, what with the
#ifdef/else/ifdef/else/ifdef/else chain to get the right include file.

Let me know if you don't want the job, and I'll do the autoconf way
instead.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132600&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 23:31:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 15:31:42 -0800
Subject: [Python-bugs-list] [Bug #133147] exec doesn't work with nested scopes
Message-ID: <E14UzmQ-0004mT-00@usw-sf-web2.sourceforge.net>

Bug #133147, was updated on 2001-Feb-19 13:53
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 5
Submitted by: mpmak
Assigned to : jhylton
Summary: exec doesn't work with nested scopes

Details: 
With latest (CVS) version of python included example won't even compile.
I&#8217;ve get same effect with reduce and filer instead of map.

def demo(xyz):
	zyx = map(lambda x: str(x), xyz)
	g = {}
	l = {}
	exec codeObject in g, l


Follow-Ups:

Date: 2001-Feb-19 15:31
By: jhylton

Comment:
The problem has nothing to do with map, filter, or reduce.  Rather,
as the exception says, "exec or 'import *' makes name ambiguous in nested
scope".  Perhaps the message is obscure but it does mention
the culprits: nested scopes and exec.

The name str in the lambda is not defined in demo().  The compiler
can't tell if the exec is going to try something like exec "str=len" .  So
it complains rather than guessing what is meant.

Either replace the lambda or the exec and it will work, e.g.

zyx = [str(x) for x in xyz]

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

Date: 2001-Feb-19 14:12
By: fdrake

Comment:
Yes; assigned to Jeremy since he can explain it or label it a real bug.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133147&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 23:36:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 15:36:44 -0800
Subject: [Python-bugs-list] [Bug #133096] Fatal python error in com_make_closure()
Message-ID: <E14UzrI-0004o3-00@usw-sf-web2.sourceforge.net>

Bug #133096, was updated on 2001-Feb-19 09:03
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: glchapman
Assigned to : jhylton
Summary: Fatal python error in com_make_closure()

Details: This construct causes python (2.1 alpha 2) to crash:

>>> def test(n):
...     return lambda fact: fact(fact, long(n))
...
lookup 'n' in test 1 -1
Fatal Python error: com_make_closure()

To try to help narrow it down, the following works with no problem:

>>> def test(n):
...     return lambda fact: fact(fact, n)

So it appears that adding the call to the long function is breaking
something.


Follow-Ups:

Date: 2001-Feb-19 13:27
By: fdrake

Comment:
Assigned to Mr. Compiler.
-------------------------------------------------------

Date: 2001-Feb-19 10:34
By: mwh

Comment:
OTOH, I've just rebuilt and it seems to have gone away.

A bug of this kind was fixed in revision 2.163 of compile.c (on
2001/02/12)- can you try after that?
-------------------------------------------------------

Date: 2001-Feb-19 09:18
By: mwh

Comment:
Nah, it crashes on linux too.

It doesn't crash if you change almost anything about the test-case, so it's
probably some bizarre kind of dictionary traversal bug again.
-------------------------------------------------------

Date: 2001-Feb-19 09:05
By: glchapman

Comment:
I probably should have added that I'm using the Win32 compiled version
downloaded from SourceForge (operating system is Windows 2000).

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133096&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 23:38:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 15:38:29 -0800
Subject: [Python-bugs-list] [Bug #133096] Fatal python error in com_make_closure()
Message-ID: <E14Uzsz-0004op-00@usw-sf-web2.sourceforge.net>

Bug #133096, was updated on 2001-Feb-19 09:03
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: glchapman
Assigned to : jhylton
Summary: Fatal python error in com_make_closure()

Details: This construct causes python (2.1 alpha 2) to crash:

>>> def test(n):
...     return lambda fact: fact(fact, long(n))
...
lookup 'n' in test 1 -1
Fatal Python error: com_make_closure()

To try to help narrow it down, the following works with no problem:

>>> def test(n):
...     return lambda fact: fact(fact, n)

So it appears that adding the call to the long function is breaking
something.


Follow-Ups:

Date: 2001-Feb-19 15:38
By: jhylton

Comment:
This appears to work with the current CVS repository.  One of the
bug fixes this morning must have caught it.

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

Date: 2001-Feb-19 13:27
By: fdrake

Comment:
Assigned to Mr. Compiler.
-------------------------------------------------------

Date: 2001-Feb-19 10:34
By: mwh

Comment:
OTOH, I've just rebuilt and it seems to have gone away.

A bug of this kind was fixed in revision 2.163 of compile.c (on
2001/02/12)- can you try after that?
-------------------------------------------------------

Date: 2001-Feb-19 09:18
By: mwh

Comment:
Nah, it crashes on linux too.

It doesn't crash if you change almost anything about the test-case, so it's
probably some bizarre kind of dictionary traversal bug again.
-------------------------------------------------------

Date: 2001-Feb-19 09:05
By: glchapman

Comment:
I probably should have added that I'm using the Win32 compiled version
downloaded from SourceForge (operating system is Windows 2000).

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133096&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 23:38:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 15:38:40 -0800
Subject: [Python-bugs-list] [Bug #133096] Fatal python error in com_make_closure()
Message-ID: <E14UztA-0004ot-00@usw-sf-web2.sourceforge.net>

Bug #133096, was updated on 2001-Feb-19 09:03
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Submitted by: glchapman
Assigned to : jhylton
Summary: Fatal python error in com_make_closure()

Details: This construct causes python (2.1 alpha 2) to crash:

>>> def test(n):
...     return lambda fact: fact(fact, long(n))
...
lookup 'n' in test 1 -1
Fatal Python error: com_make_closure()

To try to help narrow it down, the following works with no problem:

>>> def test(n):
...     return lambda fact: fact(fact, n)

So it appears that adding the call to the long function is breaking
something.


Follow-Ups:

Date: 2001-Feb-19 15:38
By: jhylton

Comment:
This appears to work with the current CVS repository.  One of the
bug fixes this morning must have caught it.

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

Date: 2001-Feb-19 13:27
By: fdrake

Comment:
Assigned to Mr. Compiler.
-------------------------------------------------------

Date: 2001-Feb-19 10:34
By: mwh

Comment:
OTOH, I've just rebuilt and it seems to have gone away.

A bug of this kind was fixed in revision 2.163 of compile.c (on
2001/02/12)- can you try after that?
-------------------------------------------------------

Date: 2001-Feb-19 09:18
By: mwh

Comment:
Nah, it crashes on linux too.

It doesn't crash if you change almost anything about the test-case, so it's
probably some bizarre kind of dictionary traversal bug again.
-------------------------------------------------------

Date: 2001-Feb-19 09:05
By: glchapman

Comment:
I probably should have added that I'm using the Win32 compiled version
downloaded from SourceForge (operating system is Windows 2000).

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133096&group_id=5470


From noreply@sourceforge.net  Mon Feb 19 23:40:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 19 Feb 2001 15:40:02 -0800
Subject: [Python-bugs-list] [Bug #132276] make install not working
Message-ID: <E14UzuU-0004pf-00@usw-sf-web2.sourceforge.net>

Bug #132276, was updated on 2001-Feb-13 16:56
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Submitted by: nobody
Assigned to : nobody
Summary: make install not working

Details: can't figure out why im gittin this problem


# make install
./install-sh -c python /usr/local/bin/python2.1
if test -f libpython2.1.so; then \
        ./install-sh -c -m 644 libpython2.1.so /usr/local/lib; \
else    true; \
fi
if test -f ""; then \
        ./install-sh -c -m 644  /usr/local/bin; \
else    true; \
fi
Creating directory /usr/local/lib/python2.1
cp: illegal option -- d
cp: Insufficient arguments (1)
Usage: cp [-f] [-i] [-p] f1 f2
       cp [-f] [-i] [-p] f1 ... fn d1
       cp -r|R [-f] [-i] [-p] d1 ... dn-1 dn
*** Error code 2
make: Fatal error: Command failed for target `libinstall'


Follow-Ups:

Date: 2001-Feb-14 06:36
By: gvanrossum

Comment:
What platform?

To further debug this, please insert "set -x" in the install-sh script
(after the first comment block) so you can see what it's doing.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132276&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 08:12:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 00:12:07 -0800
Subject: [Python-bugs-list] [Bug #133200] cPickle does not use Py_BEGIN_ALLOW_THREADS.
Message-ID: <E14V7u3-0007kx-00@usw-sf-web1.sourceforge.net>

Bug #133200, was updated on 2001-Feb-20 00:12
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: ianbanks
Assigned to : nobody
Summary: cPickle does not use Py_BEGIN_ALLOW_THREADS.

Details: This bug refers to:

python/dist/src/Modules/cPickle.c
Revision 2.54 (In SourceForge)

The use of fread (line 506) and fwrite (line 410) are not wrapped by
Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS.

This causes certain uses of cPickle in threaded programs to deadlock, where
pickle does not.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133200&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 10:54:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 02:54:52 -0800
Subject: [Python-bugs-list] [Bug #133213] HTML rendering of >>> in doctest
Message-ID: <E14VARY-0000yl-00@usw-sf-web1.sourceforge.net>

Bug #133213, was updated on 2001-Feb-20 02:54
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: tim_one
Assigned to : fdrake
Summary: HTML rendering of >>> in doctest

Details: This is one paragraph where the LaTeX contains two instances of

\code{">>>"}

The HTML renders as two characters within the double quotes, first a &#187
entity, then a &gt entity reference.  Looks bizarre:
"»>"


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133213&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 10:55:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 02:55:05 -0800
Subject: [Python-bugs-list] [Bug #133214] HTML rendering of >>> in doctest
Message-ID: <E14VARl-0000zL-00@usw-sf-web1.sourceforge.net>

Bug #133214, was updated on 2001-Feb-20 02:54
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: tim_one
Assigned to : fdrake
Summary: HTML rendering of >>> in doctest

Details: This is one paragraph where the LaTeX contains two instances of

\code{">>>"}

The HTML renders as two characters within the double quotes, first a &#187
entity, then a &gt entity reference.  Looks bizarre:
"»>"


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133214&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 10:56:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 02:56:10 -0800
Subject: [Python-bugs-list] [Bug #133214] HTML rendering of >>> in doctest
Message-ID: <E14VASo-0000zv-00@usw-sf-web1.sourceforge.net>

Bug #133214, was updated on 2001-Feb-20 02:54
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Duplicate
Bug Group: None
Priority: 5
Submitted by: tim_one
Assigned to : nobody
Summary: HTML rendering of >>> in doctest

Details: This is one paragraph where the LaTeX contains two instances of

\code{">>>"}

The HTML renders as two characters within the double quotes, first a &#187
entity, then a &gt entity reference.  Looks bizarre:
"»>"


Follow-Ups:

Date: 2001-Feb-20 02:56
By: tim_one

Comment:
Duplicate.  Must have refreshed the original submit page (or something
...).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133214&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 15:09:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 07:09:52 -0800
Subject: [Python-bugs-list] [Bug #133253] build_ext: --define option doesn't work
Message-ID: <E14VEQK-00034z-00@usw-sf-web2.sourceforge.net>

Bug #133253, was updated on 2001-Feb-20 07:09
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: akuchling
Assigned to : nobody
Summary: build_ext: --define option doesn't work

Details: The --define switch to the build_ext command doesn't 
work -- presumably it's not putting the right contents
in the .define list.  (Wonder if setting this in setup.cfg also fails?)

ute zodb>python setup.py build_ext --define=_REENTRANT
Running BTree
running build_ext
Traceback (most recent call last):
  File "setup.py", line 24, in ?
    )
  File "/www/plat/python2.0/lib/python2.0/distutils/core.py", line 209, in
run_setup
    execfile(script_name, g, l)
  File "setup.py", line 34, in ?
    ext_modules = modlist
  File "/www/plat/python2.0/lib/python2.0/distutils/core.py", line 138, in
setup    dist.run_commands()
  File "/www/plat/python2.0/lib/python2.0/distutils/dist.py", line 829, in
run_commands
    self.run_command(cmd)
  File "/www/plat/python2.0/lib/python2.0/distutils/dist.py", line 849, in
run_command
    cmd_obj.run()
  File "/www/plat/python2.0/lib/python2.0/distutils/command/build_ext.py",
line
210, in run
    for (name,value) in self.define:
ValueError: unpack sequence of wrong size
You have mail in /var/spool/mail/akuchlin                                  
    

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133253&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 16:23:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 08:23:09 -0800
Subject: [Python-bugs-list] [Bug #133259] Ugly traceback for DistutilsPlatformError
Message-ID: <E14VFZF-0004ON-00@usw-sf-web1.sourceforge.net>

Bug #133259, was updated on 2001-Feb-20 08:23
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: gward
Assigned to : nobody
Summary: Ugly traceback for DistutilsPlatformError

Details: From Chad Lester:

> I was setting up a new redhat machine, and had forgotten to install the
> python-devel rpm.  The distutils provide a fairly ugly stack trace /
error
> message.  Luckily, it meant something to me... but it's not terribly
user
> friendly!
>    
> ...
>   File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line
> 368, in get_config_vars
>     func()
>   File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line
> 280, in _init_posix
>     raise DistutilsPlatformError, my_msg
> distutils.errors.DistutilsPlatformError: invalid Python
> installation: unable to open /usr/lib/python1.5/config/Makefile (No
such
> file or directory)
> 
> 



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133259&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 16:24:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 08:24:16 -0800
Subject: [Python-bugs-list] [Bug #133259] Ugly traceback for DistutilsPlatformError
Message-ID: <E14VFaK-0004Os-00@usw-sf-web1.sourceforge.net>

Bug #133259, was updated on 2001-Feb-20 08:23
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 3
Submitted by: gward
Assigned to : gward
Summary: Ugly traceback for DistutilsPlatformError

Details: From Chad Lester:

> I was setting up a new redhat machine, and had forgotten to install the
> python-devel rpm.  The distutils provide a fairly ugly stack trace /
error
> message.  Luckily, it meant something to me... but it's not terribly
user
> friendly!
>    
> ...
>   File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line
> 368, in get_config_vars
>     func()
>   File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line
> 280, in _init_posix
>     raise DistutilsPlatformError, my_msg
> distutils.errors.DistutilsPlatformError: invalid Python
> installation: unable to open /usr/lib/python1.5/config/Makefile (No
such
> file or directory)
> 
> 



Follow-Ups:

Date: 2001-Feb-20 08:24
By: gward

Comment:
This only applies for people installing Distutils
under Python 1.5.2, so it will only be fixed if
there is another Distutils release to support 1.5.2 --
which is unlikely.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133259&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 16:45:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 08:45:28 -0800
Subject: [Python-bugs-list] [Bug #133262] Incorrect encodings.py module imported
Message-ID: <E14VFuq-0003qb-00@usw-sf-web2.sourceforge.net>

Bug #133262, was updated on 2001-Feb-20 08:45
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: lhudson
Assigned to : nobody
Summary: Incorrect encodings.py module imported

Details: It appears that Python/codecs.c is not importing the standard
encodings package (Lib/encodings/).

If I run an interactive interpreter in a directory containing a file
encodings.py (whose contents are:
"print 'Imported my encodings' ") then I see the following:

Python 2.1a2 (#10, Feb 19 2001, 11:05:52) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> 'Hello'.encode('utf-16')
Imported my encodings
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
LookupError: unknown encoding
>>>

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133262&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 17:52:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 09:52:22 -0800
Subject: [Python-bugs-list] [Bug #133283] Different re results in Python 2.0 and 2.1a2
Message-ID: <E14VGxa-0000r2-00@usw-sf-web3.sourceforge.net>

Bug #133283, was updated on 2001-Feb-20 09:52
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: kopfarzt
Assigned to : nobody
Summary: Different re results in Python 2.0 and 2.1a2

Details: The following program produces different results in Python2.0
(1.6, 1.5.2) and Python 2.1a2:

import re
rx = re.compile (r'"(?:\\"|[^"])*?"')
print rx.match (r'"\""').group (0) 

(match a double quoted string with backslash escaped quotes)

Python 1.5.2, 1.6, 2.0: "\""
Python 2.1a2: "\"

Thanks
Peter

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133283&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 18:32:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 10:32:57 -0800
Subject: [Python-bugs-list] [Bug #133262] Incorrect encodings.py module imported
Message-ID: <E14VHar-0004wT-00@usw-sf-web2.sourceforge.net>

Bug #133262, was updated on 2001-Feb-20 08:45
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Open
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Submitted by: lhudson
Assigned to : nobody
Summary: Incorrect encodings.py module imported

Details: It appears that Python/codecs.c is not importing the standard
encodings package (Lib/encodings/).

If I run an interactive interpreter in a directory containing a file
encodings.py (whose contents are:
"print 'Imported my encodings' ") then I see the following:

Python 2.1a2 (#10, Feb 19 2001, 11:05:52) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> 'Hello'.encode('utf-16')
Imported my encodings
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
LookupError: unknown encoding
>>>

Follow-Ups:

Date: 2001-Feb-20 10:32
By: lemburg

Comment:
This is standard Python behaviour. Modules/packages in the 
current directory always override the ones which appear later
in sys.path if there's an ''-entry starting sys.path. You will
have to rename your module, sorry.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133262&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 19:44:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 11:44:07 -0800
Subject: [Python-bugs-list] [Bug #133297] cmath.asin is the same as cmath.asinh
Message-ID: <E14VIhj-0006QA-00@usw-sf-web1.sourceforge.net>

Bug #133297, was updated on 2001-Feb-20 11:44
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: cmath.asin is the same as cmath.asinh

Details: cmath.asin returns incorrect results for all arguments except 0. 
It appears that it actually returns arcsinh of its argument.

e.g. asin(2.0) gives (1.44363547518+0j) -- actually asinh(2.0) -- instead
of (pi/2-1.31695789692j).

This problem is not present in the math module.  It was also not present in
version 1.52.  It is present in version 2.0. however.  It occurs under both
NT and Windows 2000.

P.S. I object to having to upgrade to IE 5.01 to log into Sourceforge, so
no email address -- why is SSL required?

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133297&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 19:44:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 11:44:14 -0800
Subject: [Python-bugs-list] [Bug #133283] Different re results in Python 2.0 and 2.1a2
Message-ID: <E14VIhq-0006QI-00@usw-sf-web1.sourceforge.net>

Bug #133283, was updated on 2001-Feb-20 09:52
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: kopfarzt
Assigned to : effbot
Summary: Different re results in Python 2.0 and 2.1a2

Details: The following program produces different results in Python2.0
(1.6, 1.5.2) and Python 2.1a2:

import re
rx = re.compile (r'"(?:\\"|[^"])*?"')
print rx.match (r'"\""').group (0) 

(match a double quoted string with backslash escaped quotes)

Python 1.5.2, 1.6, 2.0: "\""
Python 2.1a2: "\"

Thanks
Peter

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133283&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 19:44:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 11:44:42 -0800
Subject: [Python-bugs-list] [Bug #133297] cmath.asin is the same as cmath.asinh
Message-ID: <E14VIiI-0006QX-00@usw-sf-web1.sourceforge.net>

Bug #133297, was updated on 2001-Feb-20 11:44
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : tim_one
Summary: cmath.asin is the same as cmath.asinh

Details: cmath.asin returns incorrect results for all arguments except 0. 
It appears that it actually returns arcsinh of its argument.

e.g. asin(2.0) gives (1.44363547518+0j) -- actually asinh(2.0) -- instead
of (pi/2-1.31695789692j).

This problem is not present in the math module.  It was also not present in
version 1.52.  It is present in version 2.0. however.  It occurs under both
NT and Windows 2000.

P.S. I object to having to upgrade to IE 5.01 to log into Sourceforge, so
no email address -- why is SSL required?

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133297&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 19:46:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 11:46:13 -0800
Subject: [Python-bugs-list] [Bug #133253] build_ext: --define option doesn't work
Message-ID: <E14VIjl-0005YM-00@usw-sf-web2.sourceforge.net>

Bug #133253, was updated on 2001-Feb-20 07:09
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: akuchling
Assigned to : gward
Summary: build_ext: --define option doesn't work

Details: The --define switch to the build_ext command doesn't 
work -- presumably it's not putting the right contents
in the .define list.  (Wonder if setting this in setup.cfg also fails?)

ute zodb>python setup.py build_ext --define=_REENTRANT
Running BTree
running build_ext
Traceback (most recent call last):
  File "setup.py", line 24, in ?
    )
  File "/www/plat/python2.0/lib/python2.0/distutils/core.py", line 209, in
run_setup
    execfile(script_name, g, l)
  File "setup.py", line 34, in ?
    ext_modules = modlist
  File "/www/plat/python2.0/lib/python2.0/distutils/core.py", line 138, in
setup    dist.run_commands()
  File "/www/plat/python2.0/lib/python2.0/distutils/dist.py", line 829, in
run_commands
    self.run_command(cmd)
  File "/www/plat/python2.0/lib/python2.0/distutils/dist.py", line 849, in
run_command
    cmd_obj.run()
  File "/www/plat/python2.0/lib/python2.0/distutils/command/build_ext.py",
line
210, in run
    for (name,value) in self.define:
ValueError: unpack sequence of wrong size
You have mail in /var/spool/mail/akuchlin                                  
    

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133253&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 19:51:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 11:51:09 -0800
Subject: [Python-bugs-list] [Bug #133262] Incorrect encodings.py module imported
Message-ID: <E14VIoX-0001l3-00@usw-sf-web3.sourceforge.net>

Bug #133262, was updated on 2001-Feb-20 08:45
Here is a current snapshot of the bug.

Project: Python
Category: Unicode
Status: Closed
Resolution: Wont Fix
Bug Group: Not a Bug
Priority: 5
Submitted by: lhudson
Assigned to : nobody
Summary: Incorrect encodings.py module imported

Details: It appears that Python/codecs.c is not importing the standard
encodings package (Lib/encodings/).

If I run an interactive interpreter in a directory containing a file
encodings.py (whose contents are:
"print 'Imported my encodings' ") then I see the following:

Python 2.1a2 (#10, Feb 19 2001, 11:05:52) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> 'Hello'.encode('utf-16')
Imported my encodings
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
LookupError: unknown encoding
>>>

Follow-Ups:

Date: 2001-Feb-20 11:51
By: fdrake

Comment:
This didn't get marked "closed", so I marked it.
-------------------------------------------------------

Date: 2001-Feb-20 10:32
By: lemburg

Comment:
This is standard Python behaviour. Modules/packages in the 
current directory always override the ones which appear later
in sys.path if there's an ''-entry starting sys.path. You will
have to rename your module, sorry.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133262&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 19:54:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 11:54:14 -0800
Subject: [Python-bugs-list] [Bug #133200] cPickle does not use Py_BEGIN_ALLOW_THREADS.
Message-ID: <E14VIrW-0006Wj-00@usw-sf-web1.sourceforge.net>

Bug #133200, was updated on 2001-Feb-20 00:12
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: ianbanks
Assigned to : dcjim
Summary: cPickle does not use Py_BEGIN_ALLOW_THREADS.

Details: This bug refers to:

python/dist/src/Modules/cPickle.c
Revision 2.54 (In SourceForge)

The use of fread (line 506) and fwrite (line 410) are not wrapped by
Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS.

This causes certain uses of cPickle in threaded programs to deadlock, where
pickle does not.


Follow-Ups:

Date: 2001-Feb-20 11:54
By: fdrake

Comment:
Can you provide an example that actually deadlocks?  Please provide
platform information as well.

cPckle certainly could be more thread-friendly in the way that you suggest,
but it should not actually deadlock either.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133200&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 20:38:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 12:38:41 -0800
Subject: [Python-bugs-list] [Bug #133297] cmath.asin is the same as cmath.asinh
Message-ID: <E14VJYX-00027o-00@usw-sf-web3.sourceforge.net>

Bug #133297, was updated on 2001-Feb-20 11:44
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : tim_one
Summary: cmath.asin is the same as cmath.asinh

Details: cmath.asin returns incorrect results for all arguments except 0. 
It appears that it actually returns arcsinh of its argument.

e.g. asin(2.0) gives (1.44363547518+0j) -- actually asinh(2.0) -- instead
of (pi/2-1.31695789692j).

This problem is not present in the math module.  It was also not present in
version 1.52.  It is present in version 2.0. however.  It occurs under both
NT and Windows 2000.

P.S. I object to having to upgrade to IE 5.01 to log into Sourceforge, so
no email address -- why is SSL required?

Follow-Ups:

Date: 2001-Feb-20 12:38
By: tim_one

Comment:
Agree something looks fishy, but they're not the same.

About IE 5.01 and SSL, you'll have to ask SourceForge.  I'd suggest you use
Netscape if you don't want to keep current with IE.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133297&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 21:17:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 13:17:46 -0800
Subject: [Python-bugs-list] [Bug #133200] cPickle does not use Py_BEGIN_ALLOW_THREADS.
Message-ID: <E14VKAM-0006J7-00@usw-sf-web2.sourceforge.net>

Bug #133200, was updated on 2001-Feb-20 00:12
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: ianbanks
Assigned to : dcjim
Summary: cPickle does not use Py_BEGIN_ALLOW_THREADS.

Details: This bug refers to:

python/dist/src/Modules/cPickle.c
Revision 2.54 (In SourceForge)

The use of fread (line 506) and fwrite (line 410) are not wrapped by
Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS.

This causes certain uses of cPickle in threaded programs to deadlock, where
pickle does not.


Follow-Ups:

Date: 2001-Feb-20 13:17
By: tim_one

Comment:
Releasing the global lock across I/O operations is never done to prevent
deadlocks, it's to let the OS overlap I/O with computation (or other I/O)
in some other thread.

OTOH, if the stream is connected to some network resource, it's possible
for the I/O to hang for external reasons, and without releasing the global
lock then the whole app hangs.  While not technically a deadlock, it
probably sure *looks* like one <wink>.

Jim, if you don't object, I'd be happy to put in global lock fiddling here
where appropriate (just reassign the bug report to me in that case).

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

Date: 2001-Feb-20 11:54
By: fdrake

Comment:
Can you provide an example that actually deadlocks?  Please provide
platform information as well.

cPckle certainly could be more thread-friendly in the way that you suggest,
but it should not actually deadlock either.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133200&group_id=5470


From noreply@sourceforge.net  Tue Feb 20 21:29:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 13:29:57 -0800
Subject: [Python-bugs-list] [Bug #133308] Python C-API for adding int (*getreadbufferproc) is wrong
Message-ID: <E14VKM9-0002XJ-00@usw-sf-web3.sourceforge.net>

Bug #133308, was updated on 2001-Feb-20 13:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: teoliphant
Assigned to : nobody
Summary: Python C-API for adding int (*getreadbufferproc) is wrong

Details: In all docs, the description for the routine int
(*getreadbufferproc) states that a return value of 0 means success. 
However, in order to get your object to work correctly with the "buffer"
command in Python, this routine needs to return the total size (in bytes)
of the buffer. 

This same problem may also exist for the documentation of int
(*getwritebufferproc).



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133308&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 00:07:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 16:07:32 -0800
Subject: [Python-bugs-list] [Bug #133334] --record option doesn't remove duplicate files
Message-ID: <E14VMoe-0000Zk-00@usw-sf-web1.sourceforge.net>

Bug #133334, was updated on 2001-Feb-20 16:07
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: err666
Assigned to : nobody
Summary: --record option doesn't remove duplicate files

Details: If I invoke python setup.py install --record=INSTALLED_FILES and
then feed the input of INSTALLED_FILES to RPM, RPM sometimes doesn't finish
successfully because of duplicate files. It would be very nice if distutils
would remove duplicate files from the recorded files itself.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133334&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 01:32:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 17:32:28 -0800
Subject: [Python-bugs-list] [Bug #116678] minidom doesn't raise exception for illegal children
Message-ID: <E14VO8q-0008AY-00@usw-sf-web2.sourceforge.net>

Bug #116678, was updated on 2000-Oct-11 19:30
Here is a current snapshot of the bug.

Project: Python
Category: XML
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: akuchling
Assigned to : akuchling
Summary: minidom doesn't raise exception for illegal children

Details: Some types of DOM node such as Text can't have children.
minidom doesn't check for this at all:

from xml.dom import minidom
doc = minidom.Document()
text = doc.createTextNode('lorem ipsum')
elem = doc.createElement('leaf')
text.appendChild( elem )
print text.toxml()

This outputs just 'lorem ipsum', but elem really is a child 
of text; Text.toxml() just isn't recursing because it doesn't expect to do
so.



Follow-Ups:

Date: 2001-Feb-20 17:32
By: akuchling

Comment:
Checked in a patch to fix the minor issue Fred raised, so 
this bug can now be closed.
-------------------------------------------------------

Date: 2001-Jan-19 08:17
By: akuchling

Comment:
I still have to follow up on Fred's comment; will add it to the stack...

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

Date: 2001-Jan-18 19:48
By: gvanrossum

Comment:
Nudge, nudge?  Andrew?  Anybody home? :)
-------------------------------------------------------

Date: 2001-Jan-04 07:54
By: fdrake

Comment:
Andrew, didn't you mostly fix this?  If you're done, please close the bug
report.

(One thing to check:  it doesn't look like NamedNodeMap.setNamedItem() and
.setNamedItemNS() check that the inserted node is an ATTRIBUTE_NODE; if
not, HierarchyRequestErr should be raised.)

Thanks for working on this!
-------------------------------------------------------

Date: 2000-Dec-12 13:08
By: gvanrossum

Comment:
Reassigning to Fred so he can pressure Paul into doing something about
this.
-------------------------------------------------------

Date: 2000-Nov-23 08:07
By: akuchling

Comment:
Patch #102485 has been submitted to fix this.
-------------------------------------------------------

Date: 2000-Nov-21 14:33
By: fdrake

Comment:
Oops, should re-categorize this as "XML" while I'm at it.
-------------------------------------------------------

Date: 2000-Nov-21 14:33
By: fdrake

Comment:
>From the documentation, I'd expect the Pythonic "moral equivalents" to be
raised, which would be a ValueError in the case of illegal node types.

I'll even go so far as to say that ValueError should be raised when a
second documentElement is appended, instead of a TypeError, to be more
consistent with usage else where in the standard library:  Pythonic style
is to raise a ValueError when the type of a value is right (in this case, a
DOM Node), but the specific value is not acceptable, either because it is
illegal or because it cannot be accepted given existing state (like already
having a documentElement).
-------------------------------------------------------

Date: 2000-Oct-15 07:06
By: loewis

Comment:
I believe this is not a bug, but an intended deviation from the DOM spec.
minidom (as the proposed documentation in patch 101821 explains) does
not support the IDL exceptions of module DOM, so it cannot report errors
about improper usage.
-------------------------------------------------------

Date: 2000-Oct-12 20:02
By: fdrake

Comment:
This is a bug with detecting an improper use.  It should be fixed, but need
not be for Python 2.0.  Correct use will not produce erroneous behavior. 
Reducing priority by one.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116678&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 02:17:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 18:17:53 -0800
Subject: [Python-bugs-list] [Bug #124981] zlib decompress of sync-flushed data fails
Message-ID: <E14VOqn-0004WR-00@usw-sf-web3.sourceforge.net>

Bug #124981, was updated on 2000-Dec-07 23:25
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: abo
Assigned to : akuchling
Summary: zlib decompress of sync-flushed data fails

Details: I'm not sure if this is just an undocumented limitation or a
genuine bug. I'm using python 1.5.2 on winNT.

A single decompress of a large amount (16K+) of compressed data that has
been sync-flushed fails to produce all the data up to the sync-flush. The
data remains inside the decompressor untill further compressed data or a
final flush is issued. Note that the 'unused_data' attribute does not show
that there is further data in the decompressor to process (it shows ''). 

A workaround is to decompress the data in smaller chunks. Note that
compressing data in smaller chunks is not required, as the problem is in
the decompressor, not the compressor.

The following code demonstrates the problem, and raises an exception when
the compressed data reaches 17K;

from zlib import *
from random import *

# create compressor and decompressor
c=compressobj(9)
d=decompressobj()

# try data sizes of 1-63K
for l in range(1,64):
    # generate random data stream
    a=''
    for i in range(l*1024):
        a=a+chr(randint(0,255))
    # compress, sync-flush, and decompress
    t=d.decompress(c.compress(a)+c.flush(Z_SYNC_FLUSH))
    # if decompressed data is different to input data, barf,
    if len(t) != len(a):
        print len(a),len(t),len(d.unused_data)
        raise error


Follow-Ups:

Date: 2001-Feb-20 18:17
By: akuchling

Comment:
Fixed by the checkin of patch #103373.
-------------------------------------------------------

Date: 2001-Jan-23 08:35
By: abo

Comment:
OK, patch submitted. Fire away :-)

overall the code is fairly ugly, but not too bad. I dunno if it warrents a
complete re-write, but certainly there is a heap of redundancy that could
be cleaned up. It would be a nice simple project for someone with time, but
that ain't me :-)
-------------------------------------------------------

Date: 2001-Jan-22 20:16
By: akuchling

Comment:
Yay!  Please submit your patch using the Patch Manager on SourceForge 
so that we can look at it and discuss it.  You can submit it as one big
patch; obviously correct changes can be applied right away causing the
patch to shrink, and disentangling the changes shouldn't be too
difficult.

The zlib module is really ugly code, and could probably do with a
restructuring; I've wondered before if it would be worth trashing it and
rewriting from scratch with the same API.  Maybe for 2.2...  If you want to
be ambitious and do a more serious restructuring, feel free to do so, but
it probably wouldn't get into 2.1.

And the bug has been reclassified under Extension Modules.

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

Date: 2001-Jan-22 15:34
By: abo

Comment:
Oh yeah, since I now know that it's definitely a zlibmodule.c bug, not a
documentation problem, you can probably change this bug's catagory from
"Documentation" to something more appropriate.
-------------------------------------------------------

Date: 2001-Jan-22 15:31
By: abo

Comment:
I've got a patch that I'm currently testing. When it's ready how do you
want me to submit it; through the SF patch manager?

I've analysed the code pretty extensively by now, and I believe I found a
few other potential problems (though I haven't bothered to create test
cases to trigger them). The original problem I found could affect
compression as well as decompression. There were some memory allocations
that didn't raise exceptions if they failed, and potential memory leaks
when exceptions did occur. Also, deflateEnd would be called twice in a
decompression object if it was flushed before it was destroyed.

The strange thing is compression, decompression, and both flush routines
perform basicly the same function, but they were all structured totally
differently (like they had been written by different people). Also, there
didn't seem to be any consistancy in the coding style so I didn't know what
style to use. I tried to resist fixing more than the initial problem I
identified, but in the end couldn't help myself.

As an aside, I noticed that the 2.0 version of zlibmodule.c is Python 2.0
specific (It wouldn't work on my 1.5.2 system so I had to compile 2.0 to
test my patch).

How do you want me to submit my patch; one big patch, or several smaller
ones for each fix? I have been using prcs to track my changes, but I have
been a bit lax in checking in each small change, so creating seperate
patches will take a little work.
-------------------------------------------------------

Date: 2001-Jan-20 06:22
By: abo

Comment:
OK, Christmas is over, and I didn't really get a chance to look at it
much.

However, some preliminary testing of the zlib library suggests that it is
_not_ in zlib. A c program that does the same compress/decompress of random
data using steadily increasing block sizes does not show the same
fault...

I've noticed what might be a potential problem in the inflateInit2 call in
PyZlib_decompressobj. The next_in and avail_in are not being initialized
before it's called. The zlib manual says they should be init'ed because
deflateInit will attempt to determine the compression method if it can. I'm
not sure why this hasn't tripped already... does PyObject_New zero memory
when it allocates things?

I also think I've found the main problem... the PyZlib_objdecompress
routine's main decompression loop thinks decompression is compelete when
all available input has been processed. However, it is possible that all
available input has been processed but there is more pending output. The
code as it stands does correctly allocate more space when this occurs, but
the loop terminates without calling inflate one more time.

I'm putting together a patch tomorrow. Right now I'm going to bed...
-------------------------------------------------------

Date: 2000-Dec-20 15:17
By: abo

Comment:
I have had a look at this in more detail (Python C interfacing is actually
pretty easy :-).

I dunno whether to go into details here, but I have noticed that inflate is
being called with Z_NO_FLUSH when the zlib docs suggest Z_SYNC_FLUSH or
Z_FINISH. However, the zlib implementation only treats Z_FINISH
differently, so this should not make a difference (but it might in future
versions of zlib).

As you have said, .unused_data will only contain data if something is
appended to a complete compressed object in the stream fed to a
decompressor. Perhaps the docs need something to clarify this, perhaps in
the form of an example?

I am going to write some test progs to see if it's in zlib. At this stage I
suspect that it is, and I'm hoping over christmas to get a patch done.

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

Date: 2000-Dec-19 11:48
By: akuchling

Comment:
.unused_data is really a red herring; the PyZlib_objdecompress()
loops until zst->avail_in is zero,  so .unused_data must always be zero by
definition.  (The attribute is there to support gzip-format files that may
contain multiple compressed streams concatenated together.)

I still have no idea what the documentation should say; "don't pass more
than 16K of  compressed data when you're expecting a sync-flush."  I can't
see a way to explain this coherently without a big long explanation that
will confuse people who don't care about this problem.  (Add a special
note, or known bugs subsection, maybe?)

A simple C test program should be written, in order to check if it's 
the zlib library itself that's doing this.    

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

Date: 2000-Dec-18 20:13
By: fdrake

Comment:
Andrew, please summarize what doc changes are needed, or make the changes
(whichever is easier for you is fine).
-------------------------------------------------------

Date: 2000-Dec-12 15:18
By: abo

Comment:
Further comments...

After looking at the C code, a few things became clear; I need to read more
about C/Python interfacing, and the "unused_data" attribute will only
contain data if additional data is fed to a de-compressor at the end of a
complete compressed stream.

The purpose of the "unused_data" attribute is not clear in the
documentation, so that should probably be clarified (mind you, I am looking
at pre-2.0 docs so maybe it already has?).

The failure to produce all data up to a sync-flush is something else... I'm
still looking into it. I'm not sure if it is an inherent limitation of
zlib, something that needs to be fixed in zlib, or something that needs to
be fixed in the python interface. If it is an inherent limitation, I'd like
to characterise it a bit better before documenting it. If it is something
that needs to be fixed in either zlib or the python interface, I'd like to
fix it.

Unfortunately, this is a bit beyond me at the moment, mainly in time, but
also a bit in skill (need to read the python/C interfacing documentation).
Maybe over the christmas holidays I'll get a chance to fix it.

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

Date: 2000-Dec-12 13:32
By: gvanrossum

Comment:
OK, assigned to Fred. You may ask Andrew what to write. :-)
-------------------------------------------------------

Date: 2000-Dec-08 14:50
By: abo

Comment:
I'm not that sure I'm happy with it just being marked closed. AFAIKT, the
implementation definitely doesn't do what the documentation says, so to
save people like me time when they hit it, I'prefer the bug at least be
assigned to documentation so that the limitation is documented.

>From my reading of the documentation as it stands, the fact that there is
more pending data in the decompressor should be indicated by it's
"unused_data" attribute. The tests seem to show that "decompress()" is only
processing 16K of compressed data each call, which would suggest that
"unused_data" should contain the rest. However, in all my tests that
attribute has always been empty. Perhaps the bug is in there somewhere?

Another slight strangeness, even if "unused_data" did contain something,
the only way to get it out is by feeding in more compressed data, or
issuing a flush(), thus ending the decompression...

I guess that since I've been bitten by this, it's up to me to fix it. I've
got the source to 2.0 and I'll have a look and see if I can submit a
patch.

<sigh> and I was coding this app in python to avoid coding in C :-)
-------------------------------------------------------

Date: 2000-Dec-08 09:26
By: akuchling

Comment:
Python 2.0 demonstrates the problem, too.

I'm not sure what this is: a zlibmodule bug/oversight or
simply problems with zlib's API.  Looking at zlib.h, 
it implies that you'd have to call inflate() with the
flush parameter set to Z_SYNC_FLUSH to get the remaining data. 
Unfortunately this doesn't seem to help -- .flush() method doesn't support
an argument, but when I patch zlibmodule.c to allow one,
.flush(Z_SYNC_FLUSH) always fails with a -5: buffer error, perhaps because
it expects there to be some new data.

(The DEFAULTALLOC constant in zlibmodule.c is 16K, but this 
seems to be unrelated to the problem showing up with more than 16K of data,
since changing DEFAULTALLOC to 32K or 1K makes no difference to the size of
data at which the bug shows up.)

In short, I have no idea what's at fault, or if it can or should be fixed. 
Unless you or someone else submits a patch, I'll just leave it alone, and
mark this bug as closed and "Won't fix".

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

Date: 2000-Dec-08 07:44
By: gvanrossum

Comment:
I *think* this may have been fixed in Python 2.0.

I'm assigning this to Andrew who can confirm that and close the bug report
(if it is fixed).
-------------------------------------------------------

Date: 2000-Dec-07 23:28
By: abo

Comment:
Argh... SF killed all my indents... sorry about that. You should be able to
figure it out, but if not email me and I can send a copy.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=124981&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 02:37:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 18:37:28 -0800
Subject: [Python-bugs-list] [Bug #133033] Build on a New Machine Needs Pre-existing Libs??
Message-ID: <E14VP9k-0001xo-00@usw-sf-web1.sourceforge.net>

Bug #133033, was updated on 2001-Feb-18 16:46
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : akuchling
Summary: Build on a New Machine Needs Pre-existing Libs??

Details: It seems that when one tries to build and install Python on a
machine that had no previous versions of Python on it, part of the build
and install procedure runs a Python program that imports several modules.
The problem is that at that point, no Python library or PYTHONHOME has yet
been defined and the script fails. As a result, it seems necessary to first
install a precompiled binary version of Python before one can successfully
build and install Python from scratch.
...Bob    ryodlowski@pirus.com


Follow-Ups:

Date: 2001-Feb-20 18:37
By: akuchling

Comment:
I second Fred's comment.  It should work without a preinstalled Python; if
it doesn't, please e-mail the output of the make command to 
akuchlin@mems-exchange.org.

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

Date: 2001-Feb-19 13:49
By: fdrake

Comment:
Did you get an error from actually trying this?  The current Makefile
builds a minimal Python which it then uses to continue the build process.

If your report was "inspired" by an actual failure, please give the
specific configure command you used, your platform, and a copy of the error
message.

Assigned to Andrew since this approach was based on his efforts; feel free
to re-assign if appropriate.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133033&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 02:49:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 18:49:52 -0800
Subject: [Python-bugs-list] [Bug #133297] cmath.asin is the same as cmath.asinh
Message-ID: <E14VPLk-00024H-00@usw-sf-web1.sourceforge.net>

Bug #133297, was updated on 2001-Feb-20 11:44
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : tim_one
Summary: cmath.asin is the same as cmath.asinh

Details: cmath.asin returns incorrect results for all arguments except 0. 
It appears that it actually returns arcsinh of its argument.

e.g. asin(2.0) gives (1.44363547518+0j) -- actually asinh(2.0) -- instead
of (pi/2-1.31695789692j).

This problem is not present in the math module.  It was also not present in
version 1.52.  It is present in version 2.0. however.  It occurs under both
NT and Windows 2000.

P.S. I object to having to upgrade to IE 5.01 to log into Sourceforge, so
no email address -- why is SSL required?

Follow-Ups:

Date: 2001-Feb-20 18:49
By: tim_one

Comment:
OK, complex asin was destroyed in revision 2.13 of cmathmodule.c.  This was
a contributed patch that we resisted applying for a long time, but it
appeared to do more good than harm so we just did it.

The problem:  the author *intended* to improve acosh and asinh, but
mistakely put his new code for asinh into the body of asin.  The only test
he wrote up was one where he showed that the new asinh worked better *when
implemented in Python*; had nothing to do with his after-patch code.

The other problem:  I checked some of his acosh() results against Macsyma,
and was happy enough.  IIRC, I just assumed asinh() would be similar (his
writeup showed similar tests and results for both).

The real problem:  we have no test suite for cmathmodule.  Care to write
one?

And the other real problem:  cmathmodule.c is numerically naive.

I'll sort this mess out ... later.
-------------------------------------------------------

Date: 2001-Feb-20 12:38
By: tim_one

Comment:
Agree something looks fishy, but they're not the same.

About IE 5.01 and SSL, you'll have to ask SourceForge.  I'd suggest you use
Netscape if you don't want to keep current with IE.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133297&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 03:23:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 19:23:36 -0800
Subject: [Python-bugs-list] [Bug #133297] cmath.asin is the same as cmath.asinh
Message-ID: <E14VPsO-0000Sr-00@usw-sf-web2.sourceforge.net>

Bug #133297, was updated on 2001-Feb-20 11:44
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : tim_one
Summary: cmath.asin is the same as cmath.asinh

Details: cmath.asin returns incorrect results for all arguments except 0. 
It appears that it actually returns arcsinh of its argument.

e.g. asin(2.0) gives (1.44363547518+0j) -- actually asinh(2.0) -- instead
of (pi/2-1.31695789692j).

This problem is not present in the math module.  It was also not present in
version 1.52.  It is present in version 2.0. however.  It occurs under both
NT and Windows 2000.

P.S. I object to having to upgrade to IE 5.01 to log into Sourceforge, so
no email address -- why is SSL required?

Follow-Ups:

Date: 2001-Feb-20 19:23
By: tim_one

Comment:
Closed and fixed, cmathmodule.c rev 2.23.

Here's a snippet from the after patch-version:

C:\Code\python\dist\src\PCbuild>python
Python 2.1a2 (#10, Feb 20 2001, 18:17:21) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import cmath
>>> cmath.asin(2)
(1.57079632679-1.31695789692j)
>>> cmath.asinh(2)
(1.44363547518+0j)
>>> cmath.asinh(cmath.sinh(450))
(450+0j)
>>> cmath.asinh(1e308)
(709.889355823+0j)
>>>
-------------------------------------------------------

Date: 2001-Feb-20 18:49
By: tim_one

Comment:
OK, complex asin was destroyed in revision 2.13 of cmathmodule.c.  This was
a contributed patch that we resisted applying for a long time, but it
appeared to do more good than harm so we just did it.

The problem:  the author *intended* to improve acosh and asinh, but
mistakely put his new code for asinh into the body of asin.  The only test
he wrote up was one where he showed that the new asinh worked better *when
implemented in Python*; had nothing to do with his after-patch code.

The other problem:  I checked some of his acosh() results against Macsyma,
and was happy enough.  IIRC, I just assumed asinh() would be similar (his
writeup showed similar tests and results for both).

The real problem:  we have no test suite for cmathmodule.  Care to write
one?

And the other real problem:  cmathmodule.c is numerically naive.

I'll sort this mess out ... later.
-------------------------------------------------------

Date: 2001-Feb-20 12:38
By: tim_one

Comment:
Agree something looks fishy, but they're not the same.

About IE 5.01 and SSL, you'll have to ask SourceForge.  I'd suggest you use
Netscape if you don't want to keep current with IE.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133297&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 03:33:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 19:33:22 -0800
Subject: [Python-bugs-list] [Bug #133200] cPickle does not use Py_BEGIN_ALLOW_THREADS.
Message-ID: <E14VQ1q-0002U5-00@usw-sf-web1.sourceforge.net>

Bug #133200, was updated on 2001-Feb-20 00:12
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: ianbanks
Assigned to : dcjim
Summary: cPickle does not use Py_BEGIN_ALLOW_THREADS.

Details: This bug refers to:

python/dist/src/Modules/cPickle.c
Revision 2.54 (In SourceForge)

The use of fread (line 506) and fwrite (line 410) are not wrapped by
Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS.

This causes certain uses of cPickle in threaded programs to deadlock, where
pickle does not.


Follow-Ups:

Date: 2001-Feb-20 19:33
By: ianbanks

Comment:
 1:
 2: import socket, thread, cPickle
 3: 
 4: def Consumer(socketname):
 5:     print "Consumer: (Client) Starting"
 6:     client = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
 7:     client.connect(socketname)
 8:     file = client.makefile("rb+")
 9: 
10:     print "Consumer: Loading File"
11:     print "Consumer: Loaded " + cPickle.load(file)
12:     print "Consumer: Done"
13: 
14: def Producer(socketname):
15:     # Create the Server socket.
16:     print "Producer: (Server) Starting"
17:     server = socket.socket(socket.AF_UNIX,  socket.SOCK_STREAM)
18:     server.bind(socketname)
19:     server.listen(5)
20: 
21:     # Accept a connection and create a file  object.
22:     newsocket, peer = server.accept()
23:     print "Producer: Connection Accepted"
24:     newfile = newsocket.makefile("rb+")
25: 
26:     # Dump a pickled object.
27:     print "Producer: Dumping File"
28:     cPickle.dump("Testing", newfile, 1)
29:     print "Producer: Done"
30: 
31: socketname = "/tmp/testsocket"
32: thread.start_new_thread(Producer,  (socketname,))
33: thread.start_new_thread(Consumer, (socketname,))
34: while 1:
35:     # Busy wait.
36:     pass

I think this locks up because of this sequence:

Both threads become runnable, and the Producer runs from line 15 to just
after line 24. The context switches to the Consumer and runs from line 5 to
line 11, blocking on the read() (and the underlying fread in cThreads). The
Producer tries to aquire the global lock, the Consumer waits on the "data
available" condition.

The lock-up doesn't always occur. On some systems it's easy to reproduce,
others seems to hide it.

Is it poor practice to assume simple I/O in threads won't block the entire
process? That would seem to imply that things like ThreadingMixIn derived
servers were technically subject to denial of service, and that looped-back
connections were unsafe.

It occurs on:

 o Linux 2.2.17-RAID / glibc 2.2.1 / Intel
 o Linux 2.2.18 (SMP) / glibc 2.1.3 / Intel
 o Linux 2.2.17pre4-RAI / glibc 2.1.3 / Intel

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

Date: 2001-Feb-20 13:17
By: tim_one

Comment:
Releasing the global lock across I/O operations is never done to prevent
deadlocks, it's to let the OS overlap I/O with computation (or other I/O)
in some other thread.

OTOH, if the stream is connected to some network resource, it's possible
for the I/O to hang for external reasons, and without releasing the global
lock then the whole app hangs.  While not technically a deadlock, it
probably sure *looks* like one <wink>.

Jim, if you don't object, I'd be happy to put in global lock fiddling here
where appropriate (just reassign the bug report to me in that case).

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

Date: 2001-Feb-20 11:54
By: fdrake

Comment:
Can you provide an example that actually deadlocks?  Please provide
platform information as well.

cPckle certainly could be more thread-friendly in the way that you suggest,
but it should not actually deadlock either.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133200&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 07:05:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 20 Feb 2001 23:05:08 -0800
Subject: [Python-bugs-list] [Bug #133283] Different re results in Python 2.0 and 2.1a2
Message-ID: <E14VTKm-0006NN-00@usw-sf-web3.sourceforge.net>

Bug #133283, was updated on 2001-Feb-20 09:52
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: kopfarzt
Assigned to : effbot
Summary: Different re results in Python 2.0 and 2.1a2

Details: The following program produces different results in Python2.0
(1.6, 1.5.2) and Python 2.1a2:

import re
rx = re.compile (r'"(?:\\"|[^"])*?"')
print rx.match (r'"\""').group (0) 

(match a double quoted string with backslash escaped quotes)

Python 1.5.2, 1.6, 2.0: "\""
Python 2.1a2: "\"

Thanks
Peter

Follow-Ups:

Date: 2001-Feb-20 23:05
By: effbot

Comment:
rx = re.compile (r'"(?:\\"|[^"]){,100}?"') works.

the bug is caused by an (obviously failed) attempt to minimize recursion
for "*?".  the checkin message says "I'm not 100% sure about this fix, but
I haven't managed to come up with any test case it cannot handle...". 
guess this is it ;-)

Thanks /F

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133283&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 18:22:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Feb 2001 10:22:22 -0800
Subject: [Python-bugs-list] [Bug #133450] 2.1a2: make install fails for _tkinter
Message-ID: <E14VduA-0005mE-00@usw-sf-web2.sourceforge.net>

Bug #133450, was updated on 2001-Feb-21 10:22
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: hinsen
Assigned to : nobody
Summary: 2.1a2: make install fails for _tkinter

Details: System: RedHat Linux 6.2

I did a straightforward build/install in my home directory
(--prefix=$HOME), enabling the Tkinter module in Modules/Setup. During
"make install", install complains that it can't create the directory
$HOME/lib/python2.1/lib-dynload/Modules. Inspection of the top-level
Makefile shows

SHAREDMODS= Modules/_tkinter$(SO)

which looks like the cause of the problem.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133450&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 21:10:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Feb 2001 13:10:06 -0800
Subject: [Python-bugs-list] [Bug #133489] compile leaks memory (current CVS)
Message-ID: <E14VgWU-0002sU-00@usw-sf-web1.sourceforge.net>

Bug #133489, was updated on 2001-Feb-21 13:10
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: effbot
Assigned to : nobody
Summary: compile leaks memory (current CVS)

Details: while 1: compile("print 'hello'\n", "<string>", "exec")

run it. watch your computer run out of memory. enough said ;-) /F


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133489&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 21:10:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Feb 2001 13:10:45 -0800
Subject: [Python-bugs-list] [Bug #133489] compile leaks memory (current CVS)
Message-ID: <E14VgX7-0002sm-00@usw-sf-web1.sourceforge.net>

Bug #133489, was updated on 2001-Feb-21 13:10
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: effbot
Assigned to : jhylton
Summary: compile leaks memory (current CVS)

Details: while 1: compile("print 'hello'\n", "<string>", "exec")

run it. watch your computer run out of memory. enough said ;-) /F


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133489&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 21:14:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Feb 2001 13:14:20 -0800
Subject: [Python-bugs-list] [Bug #133489] compile leaks memory (current CVS)
Message-ID: <E14Vgaa-0005B9-00@usw-sf-web3.sourceforge.net>

Bug #133489, was updated on 2001-Feb-21 13:10
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: effbot
Assigned to : bwarsaw
Summary: compile leaks memory (current CVS)

Details: while 1: compile("print 'hello'\n", "<string>", "exec")

run it. watch your computer run out of memory. enough said ;-) /F


Follow-Ups:

Date: 2001-Feb-21 13:14
By: jhylton

Comment:
Can you do an insure pass?

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133489&group_id=5470


From noreply@sourceforge.net  Wed Feb 21 22:19:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Feb 2001 14:19:30 -0800
Subject: [Python-bugs-list] [Bug #117464] clash with BSD db when building
Message-ID: <E14Vhbe-0005iL-00@usw-sf-web3.sourceforge.net>

Bug #117464, was updated on 2000-Oct-23 00:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: fleury
Assigned to : akuchling
Summary: clash with BSD db when building

Details: On RH7.0, beside the LONG_BIT issue, I came across a db.h
missmatch. 
The preprocessor directive values used in bsddbmodule.c correspond to the
/usr/include/db1/db.h file, but on my system, /usr/include/db.h points to
db3/db.h which does not define the same set of values, and does not
compile.

Compiling with the old file works, but obviously it does not link...

configure (with no options) ran trouble free.

The system is:
RedHat 7.0
gcc version 2.96 20000731 (yes with the LONG_BIT problem) 
Python 2.0 final release

Regards,
Pascal    

Follow-Ups:

Date: 2001-Feb-21 14:19
By: nobody

Comment:
good job

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

Date: 2001-Feb-16 02:47
By: twouters

Comment:
Assigned to Andrew to see if he can rewrite the bsddb detection code in
distutils, like described in bug #132600.


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

Date: 2001-Jan-20 08:51
By: twouters

Comment:
Apologies for not responding sooner, but I'm not sure how to fix this in
autoconf, except for redoing the test entirely, and PEP-229 shows good
promise for fixing this. The answer is pretty complicated anyway. db_185.h
comes with BSDDB 2 and 3, and under RedHat 7, BSDDB 1, 2 and 3 can all be
installed at the same time, in /usr/local/{db1,db2,db3}. 

I think the right fix would be to remove the autoconf stuff, and just check
for the existance of db_185.h in /usr/include/db3 or /usr/include/db2, or
the existance of db.h in /usr/include/db1, and then link with the right
library (which can be libdb-3.1.so, libdb2.so and libdb1.so on my RedHat
system. Confusing, isn't it ? :)

I'll see if I can fix something up, unless someone else does it before
me.

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

Date: 2001-Jan-02 09:13
By: montanaro

Comment:
Reassigned to Thomas Wouters because I think he has RH7.0.
I can't test this directly and haven't had time to investigate.  My
apologies for waiting so long to slough
this off to someone else.


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

Date: 2000-Nov-06 08:40
By: montanaro

Comment:
This is going to require a bit of effort.  My current scheme for detecting
whether bsddb can be built/linked or not relies on the presence or absence
of db.h and/or db_185.h.  If db_185.h is present, libdb v.2 is assumed.  If
only db.h is present, libdb v.1 is assumed.

Now Sleepycat has libdb v.3, and on RH7 it appears you can have all three
versions installed at once.  I don't yet know if bsddbmodule.c can be
built/linked with v.3 (seems likely, since db_185.h still existts), but
even if it can, configure will have to grovel around in db.h looking for
DB_VERSION_MAJOR.  If it doesn't exist, we have v.1.  If it does exist, its
value will determine what version > 1 we have.

I imagine for an autoconf whiz this will be a simple task, but it's more of
a challenge than I have time for at the moment.  Anyone want to take this
on?

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

Date: 2000-Oct-23 18:13
By: fleury

Comment:
Well, I also tried at home, where I have a vanilla RH7.0 and it compiles
perfectly.
The reported bug was on a RH6.2->RH7.0 upgraded machine.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117464&group_id=5470


From noreply@sourceforge.net  Thu Feb 22 02:02:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Feb 2001 18:02:03 -0800
Subject: [Python-bugs-list] [Bug #133532] Add warning about undefined "global"
Message-ID: <E14Vl51-0000kK-00@usw-sf-web2.sourceforge.net>

Bug #133532, was updated on 2001-Feb-21 18:02
Here is a current snapshot of the bug.

Project: Python
Category: Parser/Compiler
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: tim_one
Assigned to : jhylton
Summary: Add warning about undefined "global"

Details: The Ref Man has always said that "global" must not be used in some
contexts, but that this was currently unenforced.  We should warn about
this stuff in 2.1, so we can make it an error in a future release.

Example:

def f():
    g = 1
    global g

def f():
    print g
    global g


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133532&group_id=5470


From noreply@sourceforge.net  Thu Feb 22 03:23:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 21 Feb 2001 19:23:49 -0800
Subject: [Python-bugs-list] [Bug #133489] compile leaks memory (current CVS)
Message-ID: <E14VmM9-0007uY-00@usw-sf-web3.sourceforge.net>

Bug #133489, was updated on 2001-Feb-21 13:10
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 7
Submitted by: effbot
Assigned to : bwarsaw
Summary: compile leaks memory (current CVS)

Details: while 1: compile("print 'hello'\n", "<string>", "exec")

run it. watch your computer run out of memory. enough said ;-) /F


Follow-Ups:

Date: 2001-Feb-21 19:23
By: jhylton

Comment:
Based on inspection of the code, the following patch looks like it should
fix the problem.  It appears that the very first PySymtableEntryObject (the
one created in symtable_build()) isn't getting cleaned up.  It contains
pointers to all its children, so they aren't cleaned up either.

But if I apply this patch, the interpreter always crashes.  It doesn't seem
to crash at the same place every time, but it always does.  The stack trace
always points to a seg fault in malloc().

So I suspect the patch is correct and that the leak is masking some other
refcount bug.  If you could apply the patch and diagnose the crash, I think
we'd make more progress.

Index: Python/compile.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v
retrieving revision 2.168
diff -c -r2.168 compile.c
***************
*** 4193,4198 ****
--- 4195,4201 ----
  {
        Py_XDECREF(st->st_symbols);
        Py_XDECREF(st->st_stack);
+       Py_XDECREF(st->st_cur);
        PyMem_Free((void *)st);
  }
  
-------------------------------------------------------

Date: 2001-Feb-21 13:14
By: jhylton

Comment:
Can you do an insure pass?

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133489&group_id=5470


From noreply@sourceforge.net  Thu Feb 22 13:32:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Feb 2001 05:32:14 -0800
Subject: [Python-bugs-list] [Bug #133592] Can't execute script from a DOS partition without .py ext
Message-ID: <E14Vvqw-0004HG-00@usw-sf-web3.sourceforge.net>

Bug #133592, was updated on 2001-Feb-22 05:32
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: montanaro
Assigned to : nobody
Summary: Can't execute script from a DOS partition without .py ext

Details: I have a Python script without a .py extension on a DOS partition
that runs fine using python 1.6 and 2.0, but fails with a syntax error on
2.1.  If I copy it back to a Linux ext2fs partition or give it a .py
extension it works fine.  Diff thinks DOS and extfs versions are identical
as does cksum.

    % python cgi-bin/query   
      File "cgi-bin/query", line 88
        print "serverdir could not be loaded"
        ^
    SyntaxError: invalid syntax

(Note that there are only 87 lines in the file.)

    % python cgi-bin/query.py
    Content-type: text/plain

    ...

I placed a copy of the script at

    http://www.musi-cal.com/~skip/query

Copying it from the DOS partition to the remote system using scp
complained:

    query : ERROR..continuing to end of file anyway

This, coupled with the erroneous line number leads me to suspect the syntax
error has to do with the presence of the DOS EOF marker.



For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133592&group_id=5470


From noreply@sourceforge.net  Thu Feb 22 15:59:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Feb 2001 07:59:39 -0800
Subject: [Python-bugs-list] [Bug #133033] Build on a New Machine Needs Pre-existing Libs??
Message-ID: <E14Vy9b-0005XH-00@usw-sf-web3.sourceforge.net>

Bug #133033, was updated on 2001-Feb-18 16:46
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Works For Me
Bug Group: Not a Bug
Priority: 5
Submitted by: nobody
Assigned to : akuchling
Summary: Build on a New Machine Needs Pre-existing Libs??

Details: It seems that when one tries to build and install Python on a
machine that had no previous versions of Python on it, part of the build
and install procedure runs a Python program that imports several modules.
The problem is that at that point, no Python library or PYTHONHOME has yet
been defined and the script fails. As a result, it seems necessary to first
install a precompiled binary version of Python before one can successfully
build and install Python from scratch.
...Bob    ryodlowski@pirus.com


Follow-Ups:

Date: 2001-Feb-22 07:59
By: akuchling

Comment:
I just tried building the CVS tree with a reduced PATH and with
/usr/bin/python deleted; Python built and installed fine.  Therefore, in
the absence of an actual log demonstrating it, this bug seems to be either
spurious or fixed.  Marking as closed.

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

Date: 2001-Feb-20 18:37
By: akuchling

Comment:
I second Fred's comment.  It should work without a preinstalled Python; if
it doesn't, please e-mail the output of the make command to 
akuchlin@mems-exchange.org.

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

Date: 2001-Feb-19 13:49
By: fdrake

Comment:
Did you get an error from actually trying this?  The current Makefile
builds a minimal Python which it then uses to continue the build process.

If your report was "inspired" by an actual failure, please give the
specific configure command you used, your platform, and a copy of the error
message.

Assigned to Andrew since this approach was based on his efforts; feel free
to re-assign if appropriate.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133033&group_id=5470


From noreply@sourceforge.net  Thu Feb 22 16:05:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Feb 2001 08:05:46 -0800
Subject: [Python-bugs-list] [Bug #132600] 2.1a2 tries to build bsddb without "-ldb"
Message-ID: <E14VyFW-0005az-00@usw-sf-web3.sourceforge.net>

Bug #132600, was updated on 2001-Feb-15 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : akuchling
Summary: 2.1a2 tries to build bsddb without "-ldb"

Details: Platform: Tru64 Unix, V4.0F, Compaq C compiler version: Compaq C
V6.3-129 (dtk) on Digital UNIX V4.0F  (Rev. 1229), Compiler Driver V6.3-126
(dtk)

"make" causes setup.py to generate the following compile/link lines for the
bsddb extension:

cc -O -Olimit 1500 -I.
-I/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include -c
/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/Modules/bsddbmodule.c
-o build/temp.osf1-V4.0-alpha-2.1/bsddbmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V4.0-alpha-2.1/bsddbmodule.o -L/usr/local/lib -o
build/lib.osf1-V4.0-alpha-2.1/bsddb.so

The lack of a "-ldb" in the ld command causes "make test" to skip the bsddb
test (and "import bsddb" to fail) due to unresolved symbols. Looking at the
code in setup.py, the "-ldb" is only included if "db_185.h" is found. If
"db.h" is found instead, no "-l" is appended to the link line. Compaq Tru64
comes standard with db (a Compaq-modified 1.85 version, I believe), with
/usr/include/db.h and /usr/lib/libdb.a and /usr/shlib/libdb.so. Manually
adding "-ldb" to the above link line allows test_bsddb to run and pass.

Follow-Ups:

Date: 2001-Feb-22 08:05
By: akuchling

Comment:
I've submitted a further revised patch that tries to resolve
all the problems surrounding the bsddb module.  Does it work for you?

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

Date: 2001-Feb-19 15:07
By: mfavas

Comment:
I've just submitted a patch to setup.py to fix this - patch ID 103886.
-------------------------------------------------------

Date: 2001-Feb-16 02:47
By: twouters

Comment:
This bug is connected to at least one other bsddb bug ("clash with BSD db
when building", #117464) and maybe more. I think the solution is to rip out
all the autoconf stuff and do all the detecting in setup.py. I'm not sure
how to do it, though, and I don't have time to learn distutils right now
:-)

Andrew, assigning this (as well as the other bug) to you, so you can
consider the distutils solution. I can give you a rundown on how it should
work: basically, it should check for /usr/include/db{3,2}/db_185.h,
/usr/include/db1/db.h, /usr/include/db_185.h and /usr/include/db.h in that
order, try to find out if the found db.h is indeed version 1 (if it doesn't
contain a DB_VERSION_MAJOR #define, or it's #defined as 1, it's version 1),
and then try to find out if dbopen() is in libc or not. This all can be
written in autoconf, if it's really necessary, though it would probably
create quite a mess in bsddbmodule.c, what with the
#ifdef/else/ifdef/else/ifdef/else chain to get the right include file.

Let me know if you don't want the job, and I'll do the autoconf way
instead.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132600&group_id=5470


From noreply@sourceforge.net  Thu Feb 22 19:47:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Feb 2001 11:47:39 -0800
Subject: [Python-bugs-list] [Bug #132637] can't compile modules on AIX 4.2.1 (for real this time)
Message-ID: <E14W1iF-0000M4-00@usw-sf-web2.sourceforge.net>

Bug #132637, was updated on 2001-Feb-15 15:59
Here is a current snapshot of the bug.

Project: Python
Category: Extension Modules
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: bcollar
Assigned to : nobody
Summary: can't compile modules on AIX 4.2.1 (for real this time)

Details: Hi,

CC=cc_r CFLAGS="-O2 -qmaxmem=6000" ./configure --prefix=/development/utils
--without-gcc
make CC=cc_r OPT="-O2 -qmaxmem=6000".

I'm building 2.1a2 with patch 103679 applied (necessary for makexp_aix and
ld_so_aix to be found earlier in the process). Here's some output (it's the
same for all modules):

building '_tkinter' extension
/development/utils/lib/python2.1/config/ld_so_aix cc
-bI:/development/utils/lib/python2.1/config/python.exp
build/temp.aix-2-000310094C00-2.1/_tkinter.o
build/temp.aix-2-000310094C00-2.1/tkappinit.o -L/usr/X11/lib
-L/usr/local/lib -ltk8.0 -ltcl8.0 -lld -lX11 -o
build/lib.aix-2-000310094C00-2.1/_tkinter.so
unable to execute /development/utils/lib/python2.1/config/ld_so_aix: No
such file or directory
WARNING: building of extension "_tkinter" failed: command
'/development/utils/lib/python2.1/config/ld_so_aix' failed with exit status
1

There are TWO things I notice here:

1) ld_so_aix is in Modules, not in /development/utils/lib/python2.1/config.
In fact, there is no directory called /development/utils/lib/python2.1.

2) (copied from above)
"/development/utils/lib/python2.1/config/ld_so_aix cc"

Note it says cc, not cc_r, which is how I configured and ran make. cc_r is
darn important, since python will blow up if it's configured with threads
but you don't run cc_r.

Previously this problem was mentioned in bug #129991, which was closed when
I submitted some patches I thought solved the problem...well they were
incomplete. I don't know exactly what to patch for the above problems...


Follow-Ups:

Date: 2001-Feb-22 11:47
By: bcollar

Comment:
I got today's snapshot and ran the same configure and make I've been doing.
Lo and behold everything worked GREAT. No problems building modules at
all.
NOTE: this is using GNU make.

Good job Neil!

However, when I used AIX's make, there were a few errors while building
Modules:

./Modules/ld_so_aix cc -bI:Modules/python.exp
build/temp.aix-2-000310094C00-2.1/dlmodule.o -L/usr/local/lib -o
build/lib.aix-2-000310094C00-2.1/dl.so
ld: 0711-317 ERROR: Undefined symbol: .dlopen
ld: 0711-317 ERROR: Undefined symbol: .dlerror
ld: 0711-317 ERROR: Undefined symbol: .dlsym
ld: 0711-317 ERROR: Undefined symbol: .dlclose
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.

./Modules/ld_so_aix cc -bI:Modules/python.exp
build/temp.aix-2-000310094C00-2.1/_cursesmodule.o -L/usr/local/lib -lcurses
-ltermcap -o build/lib.aix-2-000310094C00-2.1/_curses.so
ld: 0706-006 Cannot find or open library file: -l termcap
        ld:open(): A file or directory in the path name does not exist.

While GNU make during the Module builds used "ld_so_aix cc_r" ... you'll
note that AIX's make used cc.

Shall we continue with this? Or is it sufficient to say "Please use GNU
make if you're on AIX"?
-------------------------------------------------------

Date: 2001-Feb-16 01:51
By: lemburg

Comment:
Just reading through the checkins today I fonud that Neil has
been fiddling with that code. Perhaps you ought to grab the latest
CVS snapshot and rerun the install ?!
-------------------------------------------------------

Date: 2001-Feb-16 01:45
By: lemburg

Comment:
Ok, here we go again :-)

1)  distutils assumes Python to be already installed on the machine
and thus it looks for the AIX tools in the config dir -- unfortunately,
setup.py is run before these files are installed, so it cannot find
them. Perhaps we ought to add a special case to distutils
which allows finding them anyway ?!

2) It seems as if your make doesn't copy the command line
variables into the OS environment. The setup.py file contains
explicit code which uses the OS environment variables to
choose a compiler and linker:

# When you run "make CC=altcc" or something similar, you really want
# those environment variables passed into the setup.py phase. Here's
# a small set of useful ones.
 compiler = os.environ.get('CC')
 linker_so = os.environ.get('LDSHARED')

Not sure what to do about this. It hints at another problem though:
distutils uses the settings from the Makefile per default. It seems
that in your case it is having trouble parsing that file.

BTW, why does sys.platform return for you ? (There is a switch
in distutils.sysconfig which switches on 'aix4' -- could be that
this causes the problem)
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132637&group_id=5470


From noreply@sourceforge.net  Thu Feb 22 21:15:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Feb 2001 13:15:02 -0800
Subject: [Python-bugs-list] [Bug #133665] Race condition in threading (Conditions)
Message-ID: <E14W34o-0008Hb-00@usw-sf-web1.sourceforge.net>

Bug #133665, was updated on 2001-Feb-22 13:15
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: Race condition in threading (Conditions)

Details: Here is a race condition involving a _Condition() object cond and
a predicate called condition.

Thread A executes:
	cond.acquire()
	while not condition:
		cond.wait() <--

A goes into wait():
	waiter = _allocate_lock()
	waiter.acquire()
	self.__waiters.append(waiter)
	saved_state = self._release_save() <--

A finishes that last line and is interrupted by Thread B. A has released
cond's lock, so B continues (who was previously blocked at
cond.acquire()):
	cond.acquire()
	condition = 1
	cond.notifyAll()
	cond.release()

Back to A:
	if timeout is None:
		waiter.acquire() <--

A blocks here and completely misses the notifyAll() call. Even though it
called wait() before notifyAll(), it will now wait indefinatly for the next
notify()/notifyAll() call (which may be never).
I have run into this thread race bug in my program several times. A
POSIX-like atomic operation that releases a mutex and then grabs another
would be very useful here. Any suggestions?


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133665&group_id=5470


From noreply@sourceforge.net  Thu Feb 22 21:44:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Feb 2001 13:44:26 -0800
Subject: [Python-bugs-list] [Bug #133668] install-sh has no -d option but 2.1a2 Makefile uses it
Message-ID: <E14W3XG-0002M1-00@usw-sf-web1.sourceforge.net>

Bug #133668, was updated on 2001-Feb-22 13:44
Here is a current snapshot of the bug.

Project: Python
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mengel
Assigned to : nobody
Summary: install-sh has no -d option but 2.1a2 Makefile uses it

Details: The install-sh script has no -d option to make directories, but
the
Makefile attempts to use such an option on OSF1.  I suggest the
following patch:

*** install-sh.python.orig	Thu Feb 22 15:42:30 2001
--- install-sh.python.new	Thu Feb 22 15:39:49 2001
***************
*** 25,30 ****
--- 26,32 ----
  chownprog="${CHOWNPROG-chown}"
  chgrpprog="${CHGRPPROG-chgrp}"
  stripprog="${STRIPPROG-strip}"
+ mkdirprog="${MKDIRPROG-mkdir}"
  rmprog="${RMPROG-rm}"
  
  instcmd="$mvprog"
***************
*** 58,63 ****
--- 60,73 ----
  	    shift
  	    continue;;
  
+ 	-d) mkdircmd="$mkdirprog"
+ 	    chmodcmd="$chmodprog $2"
+ 	    instcmd=":"
+ 	    src="."
+ 	    shift
+ 	    shift
+ 	    continue;;
+ 
  	-s) stripcmd="$stripprog"
  	    shift
  	    continue;;
***************
*** 106,111 ****
--- 116,122 ----
  
  # and set any options; do chmod last to preserve setuid bits
  
+ if [ x"$mkdircmd" != x ]; then $doit $mkdircmd $dsttmp; fi
  if [ x"$chowncmd" != x ]; then $doit $chowncmd $dsttmp; fi
  if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dsttmp; fi
  if [ x"$stripcmd" != x ]; then $doit $stripcmd $dsttmp; fi


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133668&group_id=5470


From noreply@sourceforge.net  Thu Feb 22 22:46:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Feb 2001 14:46:54 -0800
Subject: [Python-bugs-list] [Bug #133308] Python C-API for adding int (*getreadbufferproc) is wrong
Message-ID: <E14W4Vi-0000Tm-00@usw-sf-web3.sourceforge.net>

Bug #133308, was updated on 2001-Feb-20 13:29
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Open
Resolution: None
Bug Group: None
Priority: 6
Submitted by: teoliphant
Assigned to : gstein
Summary: Python C-API for adding int (*getreadbufferproc) is wrong

Details: In all docs, the description for the routine int
(*getreadbufferproc) states that a return value of 0 means success. 
However, in order to get your object to work correctly with the "buffer"
command in Python, this routine needs to return the total size (in bytes)
of the buffer. 

This same problem may also exist for the documentation of int
(*getwritebufferproc).



Follow-Ups:

Date: 2001-Feb-22 14:46
By: fdrake

Comment:
Greg, you're the lead for the buffer API; can you clarify or correct the
docs as appropriate?  Thanks!
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133308&group_id=5470


From noreply@sourceforge.net  Thu Feb 22 22:22:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Feb 2001 14:22:23 -0800
Subject: [Python-bugs-list] [Bug #132933] list.sort doesn't detect comparision errors
Message-ID: <E14W47z-0000Hm-00@usw-sf-web3.sourceforge.net>

Bug #132933, was updated on 2001-Feb-18 03:28
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Submitted by: effbot
Assigned to : gvanrossum
Summary: list.sort doesn't detect comparision errors

Details: 2.0 does the right thing:

Python 2.0 (#8, Jan 29 2001, 22:28:01) on win32
>>> a = [u"foo", "bär"]
>>> a.sort()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII decoding error: ordinal not in range(128)

2.1 doesn't:

Python 2.1a2 (#10, Feb 18 2001, 00:16:17) on win32
>>> a = [u"foo", "bär"]
>>> a.sort()
>>> a
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> a
['b\x84r', u'foo']
>>> a.sort()
>>> a = 10
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> a.sort()
>>> # hey, what's going on here?
...
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> quit
'Use Ctrl-Z plus Return to exit.'
(reboot)

Follow-Ups:

Date: 2001-Feb-22 14:22
By: gvanrossum

Comment:
Good catch!  This was actually not a bug in list.sort() but more generally
in rich comparisons; a comparison like cmp("\xff", u"") would set the
exception condition but not report the exception through its return value.
Fixed in CVS now.

Question: how to create a standard test for this?  I need an operation that
reliably calls PyErr_Occurred() without calling PyErr_Clear()...
-------------------------------------------------------

Date: 2001-Feb-18 07:51
By: tim_one

Comment:
Assigned to Guido, boosted priority.

In try_3way_to_rich_compare,

if (c >= 2) c = default_3way_compare(v, w);

triggers and sets c to -2.  But then that's treated like an ordinary return
value for Py_LT, and try_3way_to_rich_compare returns Py_True leaving the
error sitting on the floor.

I figure you know a lot better than I what may have changed here since 2.0
...
-------------------------------------------------------

Date: 2001-Feb-18 07:30
By: tim_one

Comment:
Under a debug build,

Python 2.1a2 (#10, Feb  8 2001, 22:47:05) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> a = [u"foo", "bär"]
[5219 refs]
>>> a.sort()
XXX undetected error
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII decoding error: ordinal not in range(128)
[5262 refs]
>>>

"XXX undetected error" looks like a good clue.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132933&group_id=5470


From noreply@sourceforge.net  Thu Feb 22 23:15:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Feb 2001 15:15:51 -0800
Subject: [Python-bugs-list] [Bug #133213] HTML rendering of >>> in doctest
Message-ID: <E14W4xj-00083F-00@usw-sf-web1.sourceforge.net>

Bug #133213, was updated on 2001-Feb-20 02:54
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: tim_one
Assigned to : fdrake
Summary: HTML rendering of >>> in doctest

Details: This is one paragraph where the LaTeX contains two instances of

\code{">>>"}

The HTML renders as two characters within the double quotes, first a &#187
entity, then a &gt entity reference.  Looks bizarre:
"»>"


Follow-Ups:

Date: 2001-Feb-22 15:15
By: fdrake

Comment:
Fixed in Doc/lib/libdoctest.tex revision 1.5.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133213&group_id=5470


From noreply@sourceforge.net  Thu Feb 22 23:58:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Feb 2001 15:58:30 -0800
Subject: [Python-bugs-list] [Bug #132600] 2.1a2 tries to build bsddb without "-ldb"
Message-ID: <E14W5d0-0002HF-00@usw-sf-web2.sourceforge.net>

Bug #132600, was updated on 2001-Feb-15 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : akuchling
Summary: 2.1a2 tries to build bsddb without "-ldb"

Details: Platform: Tru64 Unix, V4.0F, Compaq C compiler version: Compaq C
V6.3-129 (dtk) on Digital UNIX V4.0F  (Rev. 1229), Compiler Driver V6.3-126
(dtk)

"make" causes setup.py to generate the following compile/link lines for the
bsddb extension:

cc -O -Olimit 1500 -I.
-I/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include -c
/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/Modules/bsddbmodule.c
-o build/temp.osf1-V4.0-alpha-2.1/bsddbmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V4.0-alpha-2.1/bsddbmodule.o -L/usr/local/lib -o
build/lib.osf1-V4.0-alpha-2.1/bsddb.so

The lack of a "-ldb" in the ld command causes "make test" to skip the bsddb
test (and "import bsddb" to fail) due to unresolved symbols. Looking at the
code in setup.py, the "-ldb" is only included if "db_185.h" is found. If
"db.h" is found instead, no "-l" is appended to the link line. Compaq Tru64
comes standard with db (a Compaq-modified 1.85 version, I believe), with
/usr/include/db.h and /usr/lib/libdb.a and /usr/shlib/libdb.so. Manually
adding "-ldb" to the above link line allows test_bsddb to run and pass.

Follow-Ups:

Date: 2001-Feb-22 15:58
By: mfavas

Comment:
Andrew, I've just tried your revised patch - works fine on my platform,
thanks!
-------------------------------------------------------

Date: 2001-Feb-22 08:05
By: akuchling

Comment:
I've submitted a further revised patch that tries to resolve
all the problems surrounding the bsddb module.  Does it work for you?

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

Date: 2001-Feb-19 15:07
By: mfavas

Comment:
I've just submitted a patch to setup.py to fix this - patch ID 103886.
-------------------------------------------------------

Date: 2001-Feb-16 02:47
By: twouters

Comment:
This bug is connected to at least one other bsddb bug ("clash with BSD db
when building", #117464) and maybe more. I think the solution is to rip out
all the autoconf stuff and do all the detecting in setup.py. I'm not sure
how to do it, though, and I don't have time to learn distutils right now
:-)

Andrew, assigning this (as well as the other bug) to you, so you can
consider the distutils solution. I can give you a rundown on how it should
work: basically, it should check for /usr/include/db{3,2}/db_185.h,
/usr/include/db1/db.h, /usr/include/db_185.h and /usr/include/db.h in that
order, try to find out if the found db.h is indeed version 1 (if it doesn't
contain a DB_VERSION_MAJOR #define, or it's #defined as 1, it's version 1),
and then try to find out if dbopen() is in libc or not. This all can be
written in autoconf, if it's really necessary, though it would probably
create quite a mess in bsddbmodule.c, what with the
#ifdef/else/ifdef/else/ifdef/else chain to get the right include file.

Let me know if you don't want the job, and I'll do the autoconf way
instead.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132600&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 07:00:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Feb 2001 23:00:55 -0800
Subject: [Python-bugs-list] [Bug #133717] mimetools: Nice libraries don't "print"
Message-ID: <E14WCDn-000472-00@usw-sf-web3.sourceforge.net>

Bug #133717, was updated on 2001-Feb-22 23:00
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: mimetools: Nice libraries don't "print"

Details: --- /usr/local/lib/python2.0/mimetools.py       Tue Feb  6
04:26:20 2001
+++ mimetools.py        Fri Feb 23 06:55:17 2001
@@ -206,7 +206,8 @@
        try:
                temp = open(tempname, 'w')
        except IOError:
-               print '*** Cannot create temp file', `tempname`
+               # Bad library, no donut.
+               #print '*** Cannot create temp file', `tempname`
                return
        copyliteral(input, temp)
        temp.close()


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133717&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 07:01:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 22 Feb 2001 23:01:50 -0800
Subject: [Python-bugs-list] [Bug #133592] Can't execute script from a DOS partition without .py ext
Message-ID: <E14WCEg-0005YH-00@usw-sf-web2.sourceforge.net>

Bug #133592, was updated on 2001-Feb-22 05:32
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: montanaro
Assigned to : nobody
Summary: Can't execute script from a DOS partition without .py ext

Details: I have a Python script without a .py extension on a DOS partition
that runs fine using python 1.6 and 2.0, but fails with a syntax error on
2.1.  If I copy it back to a Linux ext2fs partition or give it a .py
extension it works fine.  Diff thinks DOS and extfs versions are identical
as does cksum.

    % python cgi-bin/query   
      File "cgi-bin/query", line 88
        print "serverdir could not be loaded"
        ^
    SyntaxError: invalid syntax

(Note that there are only 87 lines in the file.)

    % python cgi-bin/query.py
    Content-type: text/plain

    ...

I placed a copy of the script at

    http://www.musi-cal.com/~skip/query

Copying it from the DOS partition to the remote system using scp
complained:

    query : ERROR..continuing to end of file anyway

This, coupled with the erroneous line number leads me to suspect the syntax
error has to do with the presence of the DOS EOF marker.



Follow-Ups:

Date: 2001-Feb-22 23:01
By: tim_one

Comment:
Is this unique to this script, or does it happen for any old Python script?
 If the latter, can you come up with a minimal failing example?  If not,
there's scant reason to believe this is a Python bug.

If scp complains when you copy it, doesn't that suggest this specific file
is damaged in some way?

The DOS EOF marker is Ctrl-Z (Python chr(26)).

I observed one bizarre thing about the file I downloaded from your URL:

>>> f = open("query.txt", "rb")
>>> guts = f.read()
>>> list(guts).count(chr(0))
87
>>>

That is, it had 87 embedded null bytes, all at the end:

>>> guts[-87:] == chr(0) * 87
1
>>>

Beats me what that does!  It's not a legitimate text file, by C rules.  But
then who knows whether I successfully downloaded what you posted ...

wc query.txt
    87     231    2273 query.txt

Is that what you get?  I can't imagine why scp would care about null bytes,
though.

Face it, Skip:  your box is *hosed* <0.7 wink>.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133592&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 08:11:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 00:11:32 -0800
Subject: [Python-bugs-list] [Bug #133665] Race condition in threading (Conditions)
Message-ID: <E14WDK8-0004cw-00@usw-sf-web3.sourceforge.net>

Bug #133665, was updated on 2001-Feb-22 13:15
Here is a current snapshot of the bug.

Project: Python
Category: Threads
Status: Open
Resolution: None
Bug Group: None
Priority: 4
Submitted by: nobody
Assigned to : tim_one
Summary: Race condition in threading (Conditions)

Details: Here is a race condition involving a _Condition() object cond and
a predicate called condition.

Thread A executes:
	cond.acquire()
	while not condition:
		cond.wait() <--

A goes into wait():
	waiter = _allocate_lock()
	waiter.acquire()
	self.__waiters.append(waiter)
	saved_state = self._release_save() <--

A finishes that last line and is interrupted by Thread B. A has released
cond's lock, so B continues (who was previously blocked at
cond.acquire()):
	cond.acquire()
	condition = 1
	cond.notifyAll()
	cond.release()

Back to A:
	if timeout is None:
		waiter.acquire() <--

A blocks here and completely misses the notifyAll() call. Even though it
called wait() before notifyAll(), it will now wait indefinatly for the next
notify()/notifyAll() call (which may be never).
I have run into this thread race bug in my program several times. A
POSIX-like atomic operation that releases a mutex and then grabs another
would be very useful here. Any suggestions?


Follow-Ups:

Date: 2001-Feb-23 00:11
By: tim_one

Comment:
You're going to have to work a lot harder to convince me that A can block. 
When cond.notifyAll() is executed, *all* the waiters in self.__waiters get
released.  It's certain that the waiter W allocated by A is in
self.__waiters at that point, because the append of W was protected by the
condvar lock, and B can't do cond.notifyAll() before it does
cond.acquire().

Therefore W is in self.__waiters when cond.notifyAll() is executed;
therefore cond.notifyAll()'s

for waiter in waiters: waiter.release()

executes W.release() in particular; therefore A's W.acquire() succeeds
sooner or later after that.

IOW, A cannot block on waiter.acquire(), because notifyAll() does
waiter.release().

I agree this *would* be a bug if A could block here, but, as above, I see
no reason to believe that it can.

Have reduced priority, and will close as NotABug tomorrow in the absence of
more info.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133665&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 11:45:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 03:45:55 -0800
Subject: [Python-bugs-list] [Bug #131064] sys.path not set correctly in embedded python interpreter.
Message-ID: <E14WGfb-0007os-00@usw-sf-web2.sourceforge.net>

Bug #131064, was updated on 2001-Feb-05 01:54
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Submitted by: theller
Assigned to : mhammond
Summary: sys.path not set correctly in embedded python interpreter.

Details: sys.path is not set correctly in an embedded python interpreter
under the following conditions:
- win98, win95 (NOT NT or win2000)
- There are no subkeys present in the registry under
HKLM\Software\Python\PythonCore\x.x\PythonPath
  (in other words, win32all is NOT installed)

The call to 
			rc = RegQueryValueEx(newKey, NULL, 0, NULL, 
			                     (LPBYTE)szCur, &dataSize);
in PC\getpathp.c, line 307 fails with error code 234 (More data is
available).
There is no check for an error.
The result is that pythonpath is not zero terminated, and contains
garbage.
The call fails because the buffer size specified in dataSize is one byte
too small.
It does not fail on NT or 2000, because dataSize (as got by the call to
RegQueryInfoKey)
seems to be enough for a UNICODE string.

This bug is also already in Python2.0.


Follow-Ups:

Date: 2001-Feb-23 03:45
By: mhammond

Comment:
Fixed in rev 1.23 of PC/getpath.c.  See patch #103933.
-------------------------------------------------------

Date: 2001-Feb-05 11:52
By: tim_one

Comment:
Assigned to Mark.  Mark, I only skimmed this.  Assigned to you cuz I'll be
out of town the rest of the week.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=131064&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 11:46:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 03:46:38 -0800
Subject: [Python-bugs-list] [Bug #129584] pythonpath registry value ignored in 2.0
Message-ID: <E14WGgI-0007p9-00@usw-sf-web2.sourceforge.net>

Bug #129584, was updated on 2001-Jan-21 04:48
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Submitted by: esasaki
Assigned to : mhammond
Summary: pythonpath registry value ignored in 2.0

Details: The value of the HKLM\software\python\pythoncore\2.0\pythonpath
key is now ignored in Python 2.0 unless you have at least one subkey
underneath it. Since the default installation program doesn't add any
subkeys, users familiar with 1.5.2 who expect to just set pythonpath
in the registry will be disappointed.

I imagine that you all probably run with other extensions installed that
add subkeys under pythonpath and thus never see this bug. However, the
first thing I did after installing 2.0 was to try to point to my custom
libs. 5 hours later I can finally start testing to see if they still work
:).

This problem is undoubtedly related to bug 127722. Fix that and you'll fix
this one.


Follow-Ups:

Date: 2001-Feb-23 03:46
By: mhammond

Comment:
Fixed in rev 1.23 of PC/getpath.c.  See patch #103933
-------------------------------------------------------

Date: 2001-Jan-31 00:00
By: mhammond

Comment:
Doh - typing before thinking again :-(  This could potentially be very
dangerous.  If you are embedding _and_ have your own Python installation
used by your embedded app, there is a risk that a "vanilla" Python will be
located by the path search.

If I get my way and Python on Windows can determine its home based on the
sys.path it has loaded, then this should solve your problem without
resorting to a path search.  If Python does this, then I can't think of a
scenario where searching PATH will give a better results.
Can you give a scenario for embedding where
-------------------------------------------------------

Date: 2001-Jan-30 23:54
By: mhammond

Comment:
Yep - I agree with that, I suppose.  If all else fails, searching the path
sounds reasonable.  As per my comments in
https://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=128685, I
will soon be submitting a bug to enhance the PYTHONHOME determination, and
will roll this into the same report.
-------------------------------------------------------

Date: 2001-Jan-30 20:53
By: mhammond

Comment:
I can not reproduce this.  I believe the "problem" is that since Python
1.6, Python's registry search mechanism has changed.  If Python can locate
its own "home" (which it usually can, given a vanilla install) then it
_ignores_ the main registry key, and _only_ looks in subkeys.  The
rationalle is that this will allow you to have multiple installations of
the same Python version (eg, the "official" release and the current CVS
version).  This will ensure the "core" path is always correct.

To test this, copy "python.exe" to a temp directory, and run it from there.
 In this case Python will not be able to locate its home, and will use the
registry key.

I am leaving this bug open to remind me to add documentation on the
registry somewhere appropriate.  However, I am marking as "works for me".
-------------------------------------------------------

Date: 2001-Jan-21 10:41
By: tim_one

Comment:
Mark?  You know more about this than everyone else combined.  Is that good
news or bad <wink>?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129584&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 11:49:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 03:49:59 -0800
Subject: [Python-bugs-list] [Bug #127722] getpythonregpath fails
Message-ID: <E14WGjX-0007qe-00@usw-sf-web2.sourceforge.net>

Bug #127722, was updated on 2001-Jan-05 21:16
Here is a current snapshot of the bug.

Project: Python
Category: Windows
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Submitted by: effbiae
Assigned to : mhammond
Summary: getpythonregpath fails

Details: Hi,

I'm on Win95 (regrettably).

I found that while experimenting with embedding Python in C, I initialized
the interpreter, and got the message:
  'import site' failed; use -v for traceback

If I putenv("PYTHONHOME=C:\python20"), this disappears.  Also, if I put the
executable in C:\python20, the problem disappears.  

Please excuse any stupidity that follows as I am a newby to the windows
registy.

in the file:
  Pc\getpathp.c

in the function:
  static char *
  getpythonregpath(HKEY keyBase, int skipcore)

in the call:
  rc = RegQueryInfoKey(newKey, NULL, NULL, NULL, &numKeys, NULL, NULL, 
	                NULL, NULL, &dataSize, NULL, NULL);

numKeys is being set to 0 because in my installation of Python 2.0, the
registry key:
  HKEY_LOCAL_MACHINE\\Software\\Python\\PythonCore\\PythonPath\

has no subkeys. It has the 'default' (?) value:
  
C:\Python20\Lib\plat-win;C:\Python20\Lib;C:\Python20\DLLs;C:\Python20\Lib\lib-tk

(I do not have HKEY_CURRENT_USER\\Software\\Python\\PythonCore\\PythonPath 
-- in fact I do not have HKEY_CURRENT_USER\\Software\\Python)

Anyway, it looks like the code assumes 'numKeys > 0', which is not the case
at my run-time.

It appears that the the registry editing part of the installation program
may have changed recently, and this file has not been updated accordingly. 


Also, the doco for the Python/C API says that the PATH environment variable
may be examined to locate the python executable, but it appears that in the
Win version of Python2.0, PATH is ignored.  Is there a reason why PATH is
not examined in the Win version?



Follow-Ups:

Date: 2001-Feb-23 03:49
By: mhammond

Comment:
Fixed in rev 1.23 of PC/getpath.c.  See patch #103933
-------------------------------------------------------

Date: 2001-Jan-30 21:01
By: mhammond

Comment:
This is "by design" - see my comments at
https://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=129584

Note that there is no default that uses absolute paths (ie, the "C:\..."
you referenced).  This is the Python code determining its own core, and
thereby ignoring the registry key for the core (sub-keys are still used)

I believe the code you reference is fine, and working as designed (but that
may not be how you like <wink>).  My testing shows the code working in an
identical fashion regardless of the number of subkeys.

Also, setting PYTHONHOME is working as designed - this env var tells Python
to not search for its home, and to not use the registry key, but assume the
directory specified is valid, and build its core path from that.

Marking as "works for me" and closing.
-------------------------------------------------------

Date: 2001-Jan-09 17:13
By: mhammond

Comment:
Happy to look at this, but it will probably need to wait until I return to
Oz - early Feb.
-------------------------------------------------------

Date: 2001-Jan-07 21:37
By: tim_one

Comment:
Assigned to MarkH cuz he might actually think he knows what the code is
doing <wink..
-------------------------------------------------------

Date: 2001-Jan-07 15:48
By: fdrake

Comment:
Assigned to Tim since this is on Windows.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=127722&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 16:34:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 08:34:08 -0800
Subject: [Python-bugs-list] [Bug #132600] 2.1a2 tries to build bsddb without "-ldb"
Message-ID: <E14WLAW-0000d3-00@usw-sf-web3.sourceforge.net>

Bug #132600, was updated on 2001-Feb-15 12:51
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : akuchling
Summary: 2.1a2 tries to build bsddb without "-ldb"

Details: Platform: Tru64 Unix, V4.0F, Compaq C compiler version: Compaq C
V6.3-129 (dtk) on Digital UNIX V4.0F  (Rev. 1229), Compiler Driver V6.3-126
(dtk)

"make" causes setup.py to generate the following compile/link lines for the
bsddb extension:

cc -O -Olimit 1500 -I.
-I/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include -c
/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/Modules/bsddbmodule.c
-o build/temp.osf1-V4.0-alpha-2.1/bsddbmodule.o
ld -shared -expect_unresolved *
build/temp.osf1-V4.0-alpha-2.1/bsddbmodule.o -L/usr/local/lib -o
build/lib.osf1-V4.0-alpha-2.1/bsddb.so

The lack of a "-ldb" in the ld command causes "make test" to skip the bsddb
test (and "import bsddb" to fail) due to unresolved symbols. Looking at the
code in setup.py, the "-ldb" is only included if "db_185.h" is found. If
"db.h" is found instead, no "-l" is appended to the link line. Compaq Tru64
comes standard with db (a Compaq-modified 1.85 version, I believe), with
/usr/include/db.h and /usr/lib/libdb.a and /usr/shlib/libdb.so. Manually
adding "-ldb" to the above link line allows test_bsddb to run and pass.

Follow-Ups:

Date: 2001-Feb-23 08:34
By: akuchling

Comment:
Apparently fixed by patch #103937. 
-------------------------------------------------------

Date: 2001-Feb-22 15:58
By: mfavas

Comment:
Andrew, I've just tried your revised patch - works fine on my platform,
thanks!
-------------------------------------------------------

Date: 2001-Feb-22 08:05
By: akuchling

Comment:
I've submitted a further revised patch that tries to resolve
all the problems surrounding the bsddb module.  Does it work for you?

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

Date: 2001-Feb-19 15:07
By: mfavas

Comment:
I've just submitted a patch to setup.py to fix this - patch ID 103886.
-------------------------------------------------------

Date: 2001-Feb-16 02:47
By: twouters

Comment:
This bug is connected to at least one other bsddb bug ("clash with BSD db
when building", #117464) and maybe more. I think the solution is to rip out
all the autoconf stuff and do all the detecting in setup.py. I'm not sure
how to do it, though, and I don't have time to learn distutils right now
:-)

Andrew, assigning this (as well as the other bug) to you, so you can
consider the distutils solution. I can give you a rundown on how it should
work: basically, it should check for /usr/include/db{3,2}/db_185.h,
/usr/include/db1/db.h, /usr/include/db_185.h and /usr/include/db.h in that
order, try to find out if the found db.h is indeed version 1 (if it doesn't
contain a DB_VERSION_MAJOR #define, or it's #defined as 1, it's version 1),
and then try to find out if dbopen() is in libc or not. This all can be
written in autoconf, if it's really necessary, though it would probably
create quite a mess in bsddbmodule.c, what with the
#ifdef/else/ifdef/else/ifdef/else chain to get the right include file.

Let me know if you don't want the job, and I'll do the autoconf way
instead.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132600&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 16:34:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 08:34:54 -0800
Subject: [Python-bugs-list] [Bug #117464] clash with BSD db when building
Message-ID: <E14WLBG-0000dT-00@usw-sf-web3.sourceforge.net>

Bug #117464, was updated on 2000-Oct-23 00:29
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Closed
Resolution: Fixed
Bug Group: Platform-specific
Priority: 5
Submitted by: fleury
Assigned to : akuchling
Summary: clash with BSD db when building

Details: On RH7.0, beside the LONG_BIT issue, I came across a db.h
missmatch. 
The preprocessor directive values used in bsddbmodule.c correspond to the
/usr/include/db1/db.h file, but on my system, /usr/include/db.h points to
db3/db.h which does not define the same set of values, and does not
compile.

Compiling with the old file works, but obviously it does not link...

configure (with no options) ran trouble free.

The system is:
RedHat 7.0
gcc version 2.96 20000731 (yes with the LONG_BIT problem) 
Python 2.0 final release

Regards,
Pascal    

Follow-Ups:

Date: 2001-Feb-23 08:34
By: akuchling

Comment:
Apparently fixed by patch #103937.
-------------------------------------------------------

Date: 2001-Feb-21 14:19
By: nobody

Comment:
good job

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

Date: 2001-Feb-16 02:47
By: twouters

Comment:
Assigned to Andrew to see if he can rewrite the bsddb detection code in
distutils, like described in bug #132600.


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

Date: 2001-Jan-20 08:51
By: twouters

Comment:
Apologies for not responding sooner, but I'm not sure how to fix this in
autoconf, except for redoing the test entirely, and PEP-229 shows good
promise for fixing this. The answer is pretty complicated anyway. db_185.h
comes with BSDDB 2 and 3, and under RedHat 7, BSDDB 1, 2 and 3 can all be
installed at the same time, in /usr/local/{db1,db2,db3}. 

I think the right fix would be to remove the autoconf stuff, and just check
for the existance of db_185.h in /usr/include/db3 or /usr/include/db2, or
the existance of db.h in /usr/include/db1, and then link with the right
library (which can be libdb-3.1.so, libdb2.so and libdb1.so on my RedHat
system. Confusing, isn't it ? :)

I'll see if I can fix something up, unless someone else does it before
me.

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

Date: 2001-Jan-02 09:13
By: montanaro

Comment:
Reassigned to Thomas Wouters because I think he has RH7.0.
I can't test this directly and haven't had time to investigate.  My
apologies for waiting so long to slough
this off to someone else.


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

Date: 2000-Nov-06 08:40
By: montanaro

Comment:
This is going to require a bit of effort.  My current scheme for detecting
whether bsddb can be built/linked or not relies on the presence or absence
of db.h and/or db_185.h.  If db_185.h is present, libdb v.2 is assumed.  If
only db.h is present, libdb v.1 is assumed.

Now Sleepycat has libdb v.3, and on RH7 it appears you can have all three
versions installed at once.  I don't yet know if bsddbmodule.c can be
built/linked with v.3 (seems likely, since db_185.h still existts), but
even if it can, configure will have to grovel around in db.h looking for
DB_VERSION_MAJOR.  If it doesn't exist, we have v.1.  If it does exist, its
value will determine what version > 1 we have.

I imagine for an autoconf whiz this will be a simple task, but it's more of
a challenge than I have time for at the moment.  Anyone want to take this
on?

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

Date: 2000-Oct-23 18:13
By: fleury

Comment:
Well, I also tried at home, where I have a vanilla RH7.0 and it compiles
perfectly.
The reported bug was on a RH6.2->RH7.0 upgraded machine.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=117464&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 16:45:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 08:45:18 -0800
Subject: [Python-bugs-list] [Bug #132606] 2.1a2 _tkinter build may pick up wrong Tcl/Tk versions
Message-ID: <E14WLLK-00026K-00@usw-sf-web2.sourceforge.net>

Bug #132606, was updated on 2001-Feb-15 13:21
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : akuchling
Summary: 2.1a2 _tkinter build may pick up wrong Tcl/Tk versions

Details: Platform: Compaq Tru64 Unix, Version 4.0F, Compaq C V6.3-129 (dtk)
on Digital UNIX V4.0F  (Rev. 1229), Compiler Driver V6.3-126 (dtk) cc
Driver

setup.py generates the following compile and link lines for _tkinter.c:

cc -O -Olimit 1500 -DWITH_APPINIT=1 -I/usr/X11/include -I.
-I/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include -c
/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/Modules/
_tkinter.c -o build/temp.osf1-V4.0-alpha-2.1/_tkinter.o
cc -O -Olimit 1500 -DWITH_APPINIT=1 -I/usr/X11/include -I.
-I/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/./Include
-IInclude/ -I/usr/local/include -c
/home/gonzo1/mark/groucho1/mark/src/python/CVS/python/dist/src/Modules/
tkappinit.c -o build/temp.osf1-V4.0-alpha-2.1/tkappinit.o
ld -shared -expect_unresolved * build/temp.osf1-V4.0-alpha-2.1/_tkinter.o
build/
temp.osf1-V4.0-alpha-2.1/tkappinit.o -L/usr/X11/lib -L/usr/local/lib
-ltk8.0 -lt
cl8.0 -lX11 -o build/lib.osf1-V4.0-alpha-2.1/_tkinter.so

/usr/X11/include precedes /usr/local/include and /usr/X11/lib precedes
/usr/local/lib and will be searched first.  /usr/X11/{include,lib} are,
according to the comment in setup.py, the default location for X11. If a
system comes with Tcl/Tk installed, and the user installs a later version
in /usr/local, setup.py will use the earlier version's include files and
(probably) the later versions library files, assuming the version number is
part of the library filename and "-l{tcl,tk}" string. This mismatch will
not be good... This is the case with Tru64, which comes with an old (7.6)
version of Tcl/Tk. The only reason I didn't fall foul of this gotcha was
that Tru64 doesn't have a /usr/X11 directory - it has the standard (but
probably pre-Linux standard!) /usr/include/X11 and /usr/lib/X11 structure.
I'd suggest that for both the includes and libs /usr/local should appear
before the "default" system X11 directories.


Follow-Ups:

Date: 2001-Feb-23 08:45
By: akuchling

Comment:
The handling of include and lib directories has changed a bit; does it
still pick up the wrong versions?
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132606&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 18:02:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 10:02:28 -0800
Subject: [Python-bugs-list] [Bug #133790] [Irix] re package does not work.
Message-ID: <E14WMY0-0002pa-00@usw-sf-web2.sourceforge.net>

Bug #133790, was updated on 2001-Feb-23 10:02
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: [Irix] re package does not work.

Details: The re package does not seem to work at all under Irix 6.5 + gcc
2.8.1 (either before or after the sre Misc Patch is applied)

Python 2.0 (#1, Feb 23 2001, 01:24:07) 
[GCC 2.8.1] on irix6
Type "copyright", "credits" or "license" for more information.
>>> import re
>>> m = re.compile("^ab$").match("ab")
>>> print m
None
>>> import pre
>>> m = pre.compile("^ab$").match("ab")
>>> print m
<pre.MatchObject instance at 10201d64>

pre serves as a reasonable substitute, but since earlier versions of Python
don't have it, one can't distribute a portable package easily.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133790&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 18:34:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 10:34:48 -0800
Subject: [Python-bugs-list] [Bug #133489] compile leaks memory (current CVS)
Message-ID: <E14WN3I-00038w-00@usw-sf-web2.sourceforge.net>

Bug #133489, was updated on 2001-Feb-21 13:10
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 7
Submitted by: effbot
Assigned to : bwarsaw
Summary: compile leaks memory (current CVS)

Details: while 1: compile("print 'hello'\n", "<string>", "exec")

run it. watch your computer run out of memory. enough said ;-) /F


Follow-Ups:

Date: 2001-Feb-23 10:34
By: bwarsaw

Comment:
Fixed in 2.169 of compile.c.
-------------------------------------------------------

Date: 2001-Feb-21 19:23
By: jhylton

Comment:
Based on inspection of the code, the following patch looks like it should
fix the problem.  It appears that the very first PySymtableEntryObject (the
one created in symtable_build()) isn't getting cleaned up.  It contains
pointers to all its children, so they aren't cleaned up either.

But if I apply this patch, the interpreter always crashes.  It doesn't seem
to crash at the same place every time, but it always does.  The stack trace
always points to a seg fault in malloc().

So I suspect the patch is correct and that the leak is masking some other
refcount bug.  If you could apply the patch and diagnose the crash, I think
we'd make more progress.

Index: Python/compile.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v
retrieving revision 2.168
diff -c -r2.168 compile.c
***************
*** 4193,4198 ****
--- 4195,4201 ----
  {
        Py_XDECREF(st->st_symbols);
        Py_XDECREF(st->st_stack);
+       Py_XDECREF(st->st_cur);
        PyMem_Free((void *)st);
  }
  
-------------------------------------------------------

Date: 2001-Feb-21 13:14
By: jhylton

Comment:
Can you do an insure pass?

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133489&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 18:37:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 10:37:12 -0800
Subject: [Python-bugs-list] [Bug #132398] Emacs Python mode bugs
Message-ID: <E14WN5c-0003AS-00@usw-sf-web2.sourceforge.net>

Bug #132398, was updated on 2001-Feb-14 13:12
Here is a current snapshot of the bug.

Project: Python
Category: demos and tools
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: gvanrossum
Assigned to : bwarsaw
Summary: Emacs Python mode bugs

Details: 1. I wish that Emacs Python mode, when I run a buffer with ^C^C,
looked at the #! line (if there is one) to choose a Python interpreter,
rather than blindly using the default.

2. Also, when I set the variable python-command to "python1.5", this
apparently has no effect -- it still uses "python".

3. Maybe I've submitted this before; each time I use ^C^CF a new buffer
with a name like /usr/tmp/python-uKA1TJ is created; these buffers just
collect dust.

Follow-Ups:

Date: 2001-Feb-23 10:37
By: bwarsaw

Comment:
I've fixed #3 in 3.110 of python-mode.el.  The other two will require some
non-trivial recoding py-execute-region and the py-which-* variables.  I'm
not immediately sure of the best way to do this, but I'll work on this for
2.1 final.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132398&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 18:58:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 10:58:02 -0800
Subject: [Python-bugs-list] [Bug #133790] [Irix] re package does not work.
Message-ID: <E14WNPm-0001uL-00@usw-sf-web3.sourceforge.net>

Bug #133790, was updated on 2001-Feb-23 10:02
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 5
Submitted by: nobody
Assigned to : effbot
Summary: [Irix] re package does not work.

Details: The re package does not seem to work at all under Irix 6.5 + gcc
2.8.1 (either before or after the sre Misc Patch is applied)

Python 2.0 (#1, Feb 23 2001, 01:24:07) 
[GCC 2.8.1] on irix6
Type "copyright", "credits" or "license" for more information.
>>> import re
>>> m = re.compile("^ab$").match("ab")
>>> print m
None
>>> import pre
>>> m = pre.compile("^ab$").match("ab")
>>> print m
<pre.MatchObject instance at 10201d64>

pre serves as a reasonable substitute, but since earlier versions of Python
don't have it, one can't distribute a portable package easily.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133790&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 18:58:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 10:58:24 -0800
Subject: [Python-bugs-list] [Bug #129810] Memore leak in pickle and cPickle
Message-ID: <E14WNQ8-0003MP-00@usw-sf-web2.sourceforge.net>

Bug #129810, was updated on 2001-Jan-23 07:28
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 5
Submitted by: vlk
Assigned to : bwarsaw
Summary: Memore leak in pickle and cPickle

Details: # When Pickler.object is used for dump typles into file and
Unpickler for 
# load from files. A loaded object are not garbage collected.
# When function dump(object,file) is used Unpickler works fine.
# Problem is in pickle and cPickle module
# tested on Python 2.0 Red Hat Linux 6.2

import cPickle			
#import pickle			 
import gc

f=open("xxx","w")
pic=cPickle.Pickler(f,1)	# ERROR
#pic=pickle.Pickler(f,1)	# ERROR
for i in range(100):
	#cPickle.dump(([long(i),long(i),long(i),long(i)],i),f)	
		# this is OK
	#pickle.dump(([long(i),long(i),long(i),long(i)],i),f)	
		# this is OK
	pic.dump(([long(i),long(i),long(i),long(i)],i))		
		# Memory leak

f.close()
gc.set_debug(gc.DEBUG_STATS)
f=open("xxx","r")
u=cPickle.Unpickler(f)
try:
	while 1:
		gc.collect()
		print u.load()
except EOFError:
	pass
f.close()

Follow-Ups:

Date: 2001-Feb-23 10:58
By: bwarsaw

Comment:
When cranking up the number of objects placed in the pickle to 10000, I do
see some memory growth when unpickling as clocked by top.  The cPickle
growth is much smaller than the pickle growth, which already appears fairly
minimal.

I will investigate further with Insure++.

I don't see how the problem could be related to __del__ since the only
thing we're dumping and loading are builtin objects (tuples, lists, longs,
and ints).
-------------------------------------------------------

Date: 2001-Jan-23 19:28
By: gvanrossum

Comment:
Barry, can you look into this?  I would first see if this is really
reproducable without using Insure++; somehow it looks a bit fishy.  Could
also be fixed in 2.1 because now modules participate in gc.  Or could have
to do with a __del__?  Also, I doubt the claim that this is a leak with
both pickle and cPickle.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129810&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 18:59:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 10:59:18 -0800
Subject: [Python-bugs-list] [Bug #129810] Memore leak in pickle and cPickle
Message-ID: <E14WNR0-0003Mp-00@usw-sf-web2.sourceforge.net>

Bug #129810, was updated on 2001-Jan-23 07:28
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: Irreproducible
Priority: 5
Submitted by: vlk
Assigned to : bwarsaw
Summary: Memore leak in pickle and cPickle

Details: # When Pickler.object is used for dump typles into file and
Unpickler for 
# load from files. A loaded object are not garbage collected.
# When function dump(object,file) is used Unpickler works fine.
# Problem is in pickle and cPickle module
# tested on Python 2.0 Red Hat Linux 6.2

import cPickle			
#import pickle			 
import gc

f=open("xxx","w")
pic=cPickle.Pickler(f,1)	# ERROR
#pic=pickle.Pickler(f,1)	# ERROR
for i in range(100):
	#cPickle.dump(([long(i),long(i),long(i),long(i)],i),f)	
		# this is OK
	#pickle.dump(([long(i),long(i),long(i),long(i)],i),f)	
		# this is OK
	pic.dump(([long(i),long(i),long(i),long(i)],i))		
		# Memory leak

f.close()
gc.set_debug(gc.DEBUG_STATS)
f=open("xxx","r")
u=cPickle.Unpickler(f)
try:
	while 1:
		gc.collect()
		print u.load()
except EOFError:
	pass
f.close()

Follow-Ups:

Date: 2001-Feb-23 10:59
By: bwarsaw

Comment:
# When Pickler.object is used for dump typles into file and Unpickler for
load
# from files. A loaded object are not garbage collected.  When function
# dump(object,file) is used Unpickler works fine.  Problem is in pickle
and
# cPickle module tested on Python 2.0 Red Hat Linux 6.2

import gc 

def main():
    fp = open('/tmp/xxx', 'w') 
    pic = pickle.Pickler(fp, 1)                   # ERROR 

    for i in range(10000):
        pickle.dump(([long(i), long(i), long(i), long(i)], i), fp) 
        # this is OK 
        pic.dump(([long(i), long(i), long(i), long(i)], i))
        # Memory leak 

    fp.close() 
    gc.set_debug(gc.DEBUG_STATS) 

    fp = open('/tmp/xxx')

    upic = pickle.Unpickler(fp)
    try: 
        while 1: 
            gc.collect() 
            print upic.load() 
    except EOFError: 
        pass

    fp.close()


if __name__ == '__main__':
    import sys
    if len(sys.argv) > 1:
        import cPickle
        pickle = cPickle
    else:
        import pickle

    main()

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

Date: 2001-Feb-23 10:58
By: bwarsaw

Comment:
When cranking up the number of objects placed in the pickle to 10000, I do
see some memory growth when unpickling as clocked by top.  The cPickle
growth is much smaller than the pickle growth, which already appears fairly
minimal.

I will investigate further with Insure++.

I don't see how the problem could be related to __del__ since the only
thing we're dumping and loading are builtin objects (tuples, lists, longs,
and ints).
-------------------------------------------------------

Date: 2001-Jan-23 19:28
By: gvanrossum

Comment:
Barry, can you look into this?  I would first see if this is really
reproducable without using Insure++; somehow it looks a bit fishy.  Could
also be fixed in 2.1 because now modules participate in gc.  Or could have
to do with a __del__?  Also, I doubt the claim that this is a leak with
both pickle and cPickle.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129810&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 19:00:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 11:00:32 -0800
Subject: [Python-bugs-list] [Bug #129810] Memore leak in pickle and cPickle
Message-ID: <E14WNSC-0003Ns-00@usw-sf-web2.sourceforge.net>

Bug #129810, was updated on 2001-Jan-23 07:28
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: vlk
Assigned to : bwarsaw
Summary: Memore leak in pickle and cPickle

Details: # When Pickler.object is used for dump typles into file and
Unpickler for 
# load from files. A loaded object are not garbage collected.
# When function dump(object,file) is used Unpickler works fine.
# Problem is in pickle and cPickle module
# tested on Python 2.0 Red Hat Linux 6.2

import cPickle			
#import pickle			 
import gc

f=open("xxx","w")
pic=cPickle.Pickler(f,1)	# ERROR
#pic=pickle.Pickler(f,1)	# ERROR
for i in range(100):
	#cPickle.dump(([long(i),long(i),long(i),long(i)],i),f)	
		# this is OK
	#pickle.dump(([long(i),long(i),long(i),long(i)],i),f)	
		# this is OK
	pic.dump(([long(i),long(i),long(i),long(i)],i))		
		# Memory leak

f.close()
gc.set_debug(gc.DEBUG_STATS)
f=open("xxx","r")
u=cPickle.Unpickler(f)
try:
	while 1:
		gc.collect()
		print u.load()
except EOFError:
	pass
f.close()

Follow-Ups:

Date: 2001-Feb-23 10:59
By: bwarsaw

Comment:
# When Pickler.object is used for dump typles into file and Unpickler for
load
# from files. A loaded object are not garbage collected.  When function
# dump(object,file) is used Unpickler works fine.  Problem is in pickle
and
# cPickle module tested on Python 2.0 Red Hat Linux 6.2

import gc 

def main():
    fp = open('/tmp/xxx', 'w') 
    pic = pickle.Pickler(fp, 1)                   # ERROR 

    for i in range(10000):
        pickle.dump(([long(i), long(i), long(i), long(i)], i), fp) 
        # this is OK 
        pic.dump(([long(i), long(i), long(i), long(i)], i))
        # Memory leak 

    fp.close() 
    gc.set_debug(gc.DEBUG_STATS) 

    fp = open('/tmp/xxx')

    upic = pickle.Unpickler(fp)
    try: 
        while 1: 
            gc.collect() 
            print upic.load() 
    except EOFError: 
        pass

    fp.close()


if __name__ == '__main__':
    import sys
    if len(sys.argv) > 1:
        import cPickle
        pickle = cPickle
    else:
        import pickle

    main()

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

Date: 2001-Feb-23 10:58
By: bwarsaw

Comment:
When cranking up the number of objects placed in the pickle to 10000, I do
see some memory growth when unpickling as clocked by top.  The cPickle
growth is much smaller than the pickle growth, which already appears fairly
minimal.

I will investigate further with Insure++.

I don't see how the problem could be related to __del__ since the only
thing we're dumping and loading are builtin objects (tuples, lists, longs,
and ints).
-------------------------------------------------------

Date: 2001-Jan-23 19:28
By: gvanrossum

Comment:
Barry, can you look into this?  I would first see if this is really
reproducable without using Insure++; somehow it looks a bit fishy.  Could
also be fixed in 2.1 because now modules participate in gc.  Or could have
to do with a __del__?  Also, I doubt the claim that this is a leak with
both pickle and cPickle.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129810&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 19:00:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 11:00:00 -0800
Subject: [Python-bugs-list] [Bug #133334] --record option doesn't remove duplicate files
Message-ID: <E14WNRg-0001vo-00@usw-sf-web3.sourceforge.net>

Bug #133334, was updated on 2001-Feb-20 16:07
Here is a current snapshot of the bug.

Project: Python
Category: Distutils
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: err666
Assigned to : akuchling
Summary: --record option doesn't remove duplicate files

Details: If I invoke python setup.py install --record=INSTALLED_FILES and
then feed the input of INSTALLED_FILES to RPM, RPM sometimes doesn't finish
successfully because of duplicate files. It would be very nice if distutils
would remove duplicate files from the recorded files itself.


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133334&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 19:01:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 11:01:21 -0800
Subject: [Python-bugs-list] [Bug #132787] 2.1a1 compiler warnings under Solaris 8 with gcc
Message-ID: <E14WNSz-0001wZ-00@usw-sf-web3.sourceforge.net>

Bug #132787, was updated on 2001-Feb-16 17:25
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : tim_one
Summary: 2.1a1 compiler warnings under Solaris 8 with gcc

Details: Platform: SunOS asafoetida 5.8 Generic_108528-04 sun4u sparc
SUNW,Ultra-60
(actually a 220R server)
Compiler: gcc version 2.95.2 19991024 (release)
2.1a2: CVS version of Feb 16

The following compiler warnings are reported:

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Objects/floatobject.o Objects/floatobject.c
Objects/floatobject.c:35: warning: function declaration isn't a prototype

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Objects/intobject.o Objects/intobject.c
Objects/intobject.c: In function `PyInt_FromString':
Objects/intobject.c:185: warning: subscript has type `char'

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Python/errors.o Python/errors.c
Python/errors.c: In function `PyErr_Format':
Python/errors.c:405: warning: subscript has type `char'
Python/errors.c:460: warning: subscript has type `char'
Python/errors.c:465: warning: subscript has type `char'
Python/errors.c:468: warning: subscript has type `char'

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Python/pythonrun.o Python/pythonrun.c
Python/pythonrun.c: In function `initsigs':
Python/pythonrun.c:1192: warning: function declaration isn't a prototype

gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H   
-c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_confstr':
./Modules/posixmodule.c:4524: warning: implicit declaration of function
`confstr'

gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H   
-c ./Modules/signalmodule.c -o Modules/signalmodule.o
./Modules/signalmodule.c:88: warning: function declaration isn't a
prototype
./Modules/signalmodule.c: In function `signal_signal':
./Modules/signalmodule.c:212: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:214: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:225: warning: function declaration isn't a
prototype
./Modules/signalmodule.c: In function `initsignal':
./Modules/signalmodule.c:332: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:336: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:355: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:357: warning: function declaration isn't a
prototype
./Modules/signalmodule.c: In function `finisignal':
./Modules/signalmodule.c:556: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:564: warning: function declaration isn't a
prototype

<gcc compile lines omitted from here down>

Modules/stropmodule.c: In function `strop_atoi':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/stropmodule.c:752:
warning: subscript has type `char'

Modules/timemodule.c: In function `time_strptime':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/timemodule.c:398:
warning: subscript has type `char'

Modules/socketmodule.c: In function `PySocket_socket':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/socketmodule.c:1854:
warning: function declaration isn't a prototype
/export/home0/mark/src/python/CVS/python/dist/src/Modules/socketmodule.c:
In function `PySocket_fromfd':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/socketmodule.c:1892:
warning: function declaration isn't a prototype

In file included from /usr/include/curses.h:23,
from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/curses.h:5,
from Include/py_curses.h:8,
from Modules/_cursesmodule.c:104:
/usr/include/widec.h:38: warning: `getwc' redefined
/usr/include/iso/wchar_iso.h:337: warning: this is the location of the
previous 
definition
/usr/include/widec.h:39: warning: `putwc' redefined
/usr/include/iso/wchar_iso.h:340: warning: this is the location of the
previous 
definition
/usr/include/widec.h:40: warning: `getwchar' redefined
/usr/include/iso/wchar_iso.h:338: warning: this is the location of the
previous 
definition
/usr/include/widec.h:41: warning: `putwchar' redefined
/usr/include/iso/wchar_iso.h:341: warning: this is the location of the
previous 
definition
Modules/_cursesmodule.c: In function `PyCurses_Putp':
Modules/_cursesmodule.c:2135: 
warning: implicit declaration of function `putp'
Modules/_cursesmodule.c: In function `PyCurses_tigetflag':
Modules/_cursesmodule.c:2219: 
warning: implicit declaration of function `tigetflag'
Modules/_cursesmodule.c: In function `PyCurses_tigetnum':
Modules/_cursesmodule.c:2232: 
warning: implicit declaration of function `tigetnum'
Modules/_cursesmodule.c: In function `PyCurses_tigetstr':
Modules/_cursesmodule.c:2245: 
warning: implicit declaration of function `tigetstr'
Modules/_cursesmodule.c:2245: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c: In function `PyCurses_tparm':
Modules/_cursesmodule.c:2270: 
warning: implicit declaration of function `tparm'
Modules/_cursesmodule.c:2270: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2273: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2276: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2279: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2282: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2285: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2288: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2291: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2294: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2297: 
warning: assignment makes pointer from integer without a cast

In file included from /usr/include/curses.h:23,
from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/curses.h:5,
from Include/py_curses.h:8,
from Modules/_curses_panel.c:15:
/usr/include/widec.h:38: warning: `getwc' redefined
/usr/include/iso/wchar_iso.h:337: warning: this is the location of the
previous 
definition
/usr/include/widec.h:39: warning: `putwc' redefined
/usr/include/iso/wchar_iso.h:340: warning: this is the location of the
previous 
definition
/usr/include/widec.h:40: warning: `getwchar' redefined
/usr/include/iso/wchar_iso.h:338: warning: this is the location of the
previous 
definition
/usr/include/widec.h:41: warning: `putwchar' redefined
/usr/include/iso/wchar_iso.h:341: warning: this is the location of the
previous 
definition
Modules/_curses_panel.c: In function `PyCursesPanel_set_panel_userptr':
Modules/_curses_panel.c:307: warning: passing arg 2 of `set_panel_userptr'
from incompatible pointer type

Modules/fpectlmodule.c: In function `fpe_reset':
Modules/fpectlmodule.c:144: warning: implicit declaration of function
`nonstandard_arithmetic'
Modules/fpectlmodule.c:145: warning: implicit declaration of function
`ieee_flags'
Modules/fpectlmodule.c:146: warning: implicit declaration of function
`ieee_handler'




For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132787&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 18:59:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 10:59:09 -0800
Subject: [Python-bugs-list] [Bug #133717] mimetools: Nice libraries don't "print"
Message-ID: <E14WNQr-0001v8-00@usw-sf-web3.sourceforge.net>

Bug #133717, was updated on 2001-Feb-22 23:00
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : fdrake
Summary: mimetools: Nice libraries don't "print"

Details: --- /usr/local/lib/python2.0/mimetools.py       Tue Feb  6
04:26:20 2001
+++ mimetools.py        Fri Feb 23 06:55:17 2001
@@ -206,7 +206,8 @@
        try:
                temp = open(tempname, 'w')
        except IOError:
-               print '*** Cannot create temp file', `tempname`
+               # Bad library, no donut.
+               #print '*** Cannot create temp file', `tempname`
                return
        copyliteral(input, temp)
        temp.close()


For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133717&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 19:28:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 11:28:29 -0800
Subject: [Python-bugs-list] [Bug #132787] 2.1a1 compiler warnings under Solaris 8 with gcc
Message-ID: <E14WNtF-0003d7-00@usw-sf-web2.sourceforge.net>

Bug #132787, was updated on 2001-Feb-16 17:25
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mfavas
Assigned to : montanaro
Summary: 2.1a1 compiler warnings under Solaris 8 with gcc

Details: Platform: SunOS asafoetida 5.8 Generic_108528-04 sun4u sparc
SUNW,Ultra-60
(actually a 220R server)
Compiler: gcc version 2.95.2 19991024 (release)
2.1a2: CVS version of Feb 16

The following compiler warnings are reported:

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Objects/floatobject.o Objects/floatobject.c
Objects/floatobject.c:35: warning: function declaration isn't a prototype

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Objects/intobject.o Objects/intobject.c
Objects/intobject.c: In function `PyInt_FromString':
Objects/intobject.c:185: warning: subscript has type `char'

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Python/errors.o Python/errors.c
Python/errors.c: In function `PyErr_Format':
Python/errors.c:405: warning: subscript has type `char'
Python/errors.c:460: warning: subscript has type `char'
Python/errors.c:465: warning: subscript has type `char'
Python/errors.c:468: warning: subscript has type `char'

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Python/pythonrun.o Python/pythonrun.c
Python/pythonrun.c: In function `initsigs':
Python/pythonrun.c:1192: warning: function declaration isn't a prototype

gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H   
-c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_confstr':
./Modules/posixmodule.c:4524: warning: implicit declaration of function
`confstr'

gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H   
-c ./Modules/signalmodule.c -o Modules/signalmodule.o
./Modules/signalmodule.c:88: warning: function declaration isn't a
prototype
./Modules/signalmodule.c: In function `signal_signal':
./Modules/signalmodule.c:212: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:214: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:225: warning: function declaration isn't a
prototype
./Modules/signalmodule.c: In function `initsignal':
./Modules/signalmodule.c:332: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:336: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:355: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:357: warning: function declaration isn't a
prototype
./Modules/signalmodule.c: In function `finisignal':
./Modules/signalmodule.c:556: warning: function declaration isn't a
prototype
./Modules/signalmodule.c:564: warning: function declaration isn't a
prototype

<gcc compile lines omitted from here down>

Modules/stropmodule.c: In function `strop_atoi':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/stropmodule.c:752:
warning: subscript has type `char'

Modules/timemodule.c: In function `time_strptime':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/timemodule.c:398:
warning: subscript has type `char'

Modules/socketmodule.c: In function `PySocket_socket':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/socketmodule.c:1854:
warning: function declaration isn't a prototype
/export/home0/mark/src/python/CVS/python/dist/src/Modules/socketmodule.c:
In function `PySocket_fromfd':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/socketmodule.c:1892:
warning: function declaration isn't a prototype

In file included from /usr/include/curses.h:23,
from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/curses.h:5,
from Include/py_curses.h:8,
from Modules/_cursesmodule.c:104:
/usr/include/widec.h:38: warning: `getwc' redefined
/usr/include/iso/wchar_iso.h:337: warning: this is the location of the
previous 
definition
/usr/include/widec.h:39: warning: `putwc' redefined
/usr/include/iso/wchar_iso.h:340: warning: this is the location of the
previous 
definition
/usr/include/widec.h:40: warning: `getwchar' redefined
/usr/include/iso/wchar_iso.h:338: warning: this is the location of the
previous 
definition
/usr/include/widec.h:41: warning: `putwchar' redefined
/usr/include/iso/wchar_iso.h:341: warning: this is the location of the
previous 
definition
Modules/_cursesmodule.c: In function `PyCurses_Putp':
Modules/_cursesmodule.c:2135: 
warning: implicit declaration of function `putp'
Modules/_cursesmodule.c: In function `PyCurses_tigetflag':
Modules/_cursesmodule.c:2219: 
warning: implicit declaration of function `tigetflag'
Modules/_cursesmodule.c: In function `PyCurses_tigetnum':
Modules/_cursesmodule.c:2232: 
warning: implicit declaration of function `tigetnum'
Modules/_cursesmodule.c: In function `PyCurses_tigetstr':
Modules/_cursesmodule.c:2245: 
warning: implicit declaration of function `tigetstr'
Modules/_cursesmodule.c:2245: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c: In function `PyCurses_tparm':
Modules/_cursesmodule.c:2270: 
warning: implicit declaration of function `tparm'
Modules/_cursesmodule.c:2270: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2273: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2276: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2279: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2282: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2285: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2288: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2291: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2294: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2297: 
warning: assignment makes pointer from integer without a cast

In file included from /usr/include/curses.h:23,
from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/curses.h:5,
from Include/py_curses.h:8,
from Modules/_curses_panel.c:15:
/usr/include/widec.h:38: warning: `getwc' redefined
/usr/include/iso/wchar_iso.h:337: warning: this is the location of the
previous 
definition
/usr/include/widec.h:39: warning: `putwc' redefined
/usr/include/iso/wchar_iso.h:340: warning: this is the location of the
previous 
definition
/usr/include/widec.h:40: warning: `getwchar' redefined
/usr/include/iso/wchar_iso.h:338: warning: this is the location of the
previous 
definition
/usr/include/widec.h:41: warning: `putwchar' redefined
/usr/include/iso/wchar_iso.h:341: warning: this is the location of the
previous 
definition
Modules/_curses_panel.c: In function `PyCursesPanel_set_panel_userptr':
Modules/_curses_panel.c:307: warning: passing arg 2 of `set_panel_userptr'
from incompatible pointer type

Modules/fpectlmodule.c: In function `fpe_reset':
Modules/fpectlmodule.c:144: warning: implicit declaration of function
`nonstandard_arithmetic'
Modules/fpectlmodule.c:145: warning: implicit declaration of function
`ieee_flags'
Modules/fpectlmodule.c:146: warning: implicit declaration of function
`ieee_handler'




Follow-Ups:

Date: 2001-Feb-23 11:28
By: tim_one

Comment:
Skip, you have time to look at this?  Most of them have to do with
Unix-specific functions (i.e., I can't test them on my box, so don't want
to change their source code).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=132787&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 19:44:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 11:44:56 -0800
Subject: [Python-bugs-list] [Bug #129718] file locking lossage
Message-ID: <E14WO9A-0003mD-00@usw-sf-web2.sourceforge.net>

Bug #129718, was updated on 2001-Jan-22 12:43
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Wont Fix
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : bwarsaw
Summary: file locking lossage

Details: (reference:
http://www.erlenstar.demon.co.uk/unix/faq_3.html#SEC35)

there are 4 ways to lock a file in unix.
fcntl, lockf, flock and dotlocking.

the only portable ways are fcntl and dotfiles. dotlocking
is more nfs-resistant. (actually the only reliable
nfs-resistant way seems to be a combination.
see eg.
http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=43491)

both fcntl and dotlock require magic incantations to
implement. therefore it is desireable to include code
to do this in the standard python library.

there is only one module in the python distribution
that implements dot-locking or fcntl() locking:
the posixfile module.

however, it is marked as obsolete(!) because someone
misguidedly thinked the sysv lockf is more portable.

this leads to a situation where the most sensible
low-effort way to implement file locking is to
either cut-n-paste code from the posixfile module,
or to call an external program (such as lockfile(1)
from the procmail package) to do it.

  -- Erno Kuusela
     erno@iki.fi


Follow-Ups:

Date: 2001-Feb-23 11:44
By: bwarsaw

Comment:
I'm not entirely sure what the bug is that you're reporting.  
Are you saying that posixfile should not be marked as obsolete?  I recently
made some minor changes (docs and symbols) to fcntl to make lockf more
understandable.

IMO, file locking is so application and platform dependent that it isn't
very useful to have higher level modules available in the standard library.
 E.g., I have a LockFile module in Mailman which is nfs-resistant, but also
supports lock breaking semantics (at the expense of occasionally stale
locks).

Thus, I think the posixfile documentation is fine, and lockf is useful in
some situations (and does work fine, at least on Linux).  So I think there
is no bug here.  If you disagree, and think posixfile should not be marked
as obsolete, please follow up to this comment and I'll reassign to Fred.
-------------------------------------------------------

Date: 2001-Feb-08 12:55
By: donnc

Comment:
It isn't the prettiest thing in Python, but
I wouldn't have thought fcntl.lockf() would
be such a problem.  I get lockf() even on Ultrix!
In every case I can find, it's implemented per
X/Open to make the same locks as fcntl(), so the
choice between one or the other is only API.
Is it worse than I know?  (I'm just a mildly
interested member of the general Python user
public, not speaking for anyone.)
-------------------------------------------------------

Date: 2001-Jan-26 10:28
By: fdrake

Comment:
Assigned to Barry, since he deals with file locking the most these days.
-------------------------------------------------------

Date: 2001-Jan-22 13:25
By: nobody

Comment:
(i apologise for the irritated tone of the above
report.)

it apperas the approach used in posixfile is not so bullet-proof either. in
addition of the layout of the flock struct being platform-dependent,
it is also (at least on linux) dependent also
of the compilation mode used. if python
is compiled with a 64-bit file offsets,
the start and len members can grow in size.
so this would either need to be done in c code
or the code should test for the file offset
size (i don't know if it's possible to find this
out in python code).

  -- erno
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=129718&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 19:52:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 11:52:23 -0800
Subject: [Python-bugs-list] [Bug #133084] nis.match('username', 'aliases') does not work under Linux
Message-ID: <E14WOGN-0002PH-00@usw-sf-web3.sourceforge.net>

Bug #133084, was updated on 2001-Feb-19 07:17
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: nis.match('username', 'aliases') does not work under Linux

Details: The exception 'nis.error: No such key in map' is thrown
when issuing

>>> nis.match('username', 'aliases')

under SuSE-Linux 6.4 and 7.0 with both Python 2.0 and 
Python 2.1a2, even if 'username' is valid and 

$ ypmatch username aliases

works.

Fix: Apply the following patch to Modules/nismodule.c

--- nismodule.c.sv      Mon Feb 19 16:12:10 2001
+++ nismodule.c Mon Feb 19 16:15:28 2001
@@ -43,7 +43,7 @@
        {"hosts",       "hosts.byname",         0},
        {"protocols",   "protocols.bynumber",   0},
        {"services",    "services.byname",      0},
-       {"aliases",     "mail.aliases",         1}, /* created with
'makedbm -a' */
+       {"aliases",     "mail.aliases",         0}, /* created with
'makedbm -a' */
        {"ethers",      "ethers.byname",        0},
        {0L,            0L,                     0}
 };


Follow-Ups:

Date: 2001-Feb-23 11:52
By: nobody

Comment:
You are all going down on this one
-------------------------------------------------------

Date: 2001-Feb-19 13:33
By: fdrake

Comment:
Can anyone confirm this bug for other platforms?  How about the fix?  I
don't have any access a network that uses NIS these days.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133084&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 19:53:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 11:53:41 -0800
Subject: [Python-bugs-list] [Bug #127699] Memory leaks using imp.load_module
Message-ID: <E14WOHd-0003qz-00@usw-sf-web2.sourceforge.net>

Bug #127699, was updated on 2001-Jan-05 12:30
Here is a current snapshot of the bug.

Project: Python
Category: Python Interpreter Core
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: cgw
Assigned to : bwarsaw
Summary: Memory leaks using imp.load_module

Details: #!/usr/bin/env python

import os
import sys
import imp

print os.getpid()

sys.path.append("/tmp")

count = 0

while (count<1000):
    modname = "testmod%s" % count
    count = count + 1

    filename = '/tmp/'  + modname + '.py'
    f  = open(filename, 'w')
    for x in range(10000):
        f.write('x%s=%s\n'%(x,x))
    f.close()
    
    modinfo = imp.find_module(modname)
    print 'loading', modname
    m = apply(imp.load_module, ('testmod',) + modinfo)
    
## run "watch -n 1 ps up <pid>
## where <pid> is the pid printed out by this program
    


Follow-Ups:

Date: 2001-Feb-23 11:53
By: bwarsaw

Comment:
I can verify that memory grows with this process.  I will run it under
insure to get more information.
-------------------------------------------------------

Date: 2001-Jan-18 19:43
By: gvanrossum

Comment:
Barry...?!?!
-------------------------------------------------------

Date: 2001-Jan-07 15:32
By: fdrake

Comment:
Assigned to Barry since he's the memory leak expert (& has the right
tools).
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=127699&group_id=5470


From noreply@sourceforge.net  Fri Feb 23 20:06:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 23 Feb 2001 12:06:24 -0800
Subject: [Python-bugs-list] [Bug #133717] mimetools: Nice libraries don't "print"
Message-ID: <E14WOTw-0002XU-00@usw-sf-web3.sourceforge.net>

Bug #133717, was updated on 2001-Feb-22 23:00
Here is a current snapshot of the bug.

Project: Python
Category: Python Library
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : fdrake
Summary: mimetools: Nice libraries don't "print"

Details: --- /usr/local/lib/python2.0/mimetools.py       Tue Feb  6
04:26:20 2001
+++ mimetools.py        Fri Feb 23 06:55:17 2001
@@ -206,7 +206,8 @@
        try:
                temp = open(tempname, 'w')
        except IOError:
-               print '*** Cannot create temp file', `tempname`
+               # Bad library, no donut.
+               #print '*** Cannot create temp file', `tempname`
                return
        copyliteral(input, temp)
        temp.close()


Follow-Ups:

Date: 2001-Feb-23 12:06
By: fdrake

Comment:
Fixed in Lib/mimetools.py revision 1.23; the exception is no longer masked,
since applications will need to know of the failure.
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133717&group_id=5470


From nobody@sourceforge.net  Sun Feb 25 15:36:29 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 25 Feb 2001 07:36:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-232815 ] getname() already in use by OS
Message-ID: <E14X3Dp-0005Vf-00@usw-sf-web2.sourceforge.net>

Artifact #232815, was updated on 2001-02-17 05:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232815&group_id=5470

Category: Unicode
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Uwe Zessin
Assigned to: Fredrik Lundh
Summary: getname() already in use by OS

Initial Comment:
There is a name-clash on OpenVMS.

modules/unicodedata.c  defines a function named 'getname'.
This collides with a function that is defined in OpenVMS's
include file '<unixio.h>'.

Here is an extract from the documentation:
]getname
]
]   Returns the file specification associated with a file descriptor.
]
]   Format
]
]   #include   <unixio.h>
]
]   char  getname   (int file_desc , char  buffer, . . . );
 [...]
]   Description
]
]   This function places the file specification in the area
] pointed to by buffer and returns that address.  The area
] pointed to by buffer should be an array large enough to
] contain a fully qualified file specification (the maximum
] length is 256 characters).

Note: 'getname' is also used in include/ucnhash.h

I guess that 'getname' does also exist on other operating
systems, but might just be included by a different header
file. Can this be changed, please?


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

Comment By: Uwe Zessin
Date: 2001-02-25 07:36

Message:
Logged In: YES 
user_id=155755

The fix is incomplete. For a clean compile I had to change:

File UNICODEOBJECT.C
 1254   if (ucnhash_CAPI->_getcode(start, s-start-1, &chr))
******
File UNICODEOBJECT.C_OLD
 1254   if (ucnhash_CAPI->getcode(start, s-start-1, &chr))

and:

File UCNHASH.H
18  int (*_getname)(Py_UCS4 code, char* buffer, int buflen);
******
File UCNHASH.H_OLD
18  int (*getname)(Py_UCS4 code, char* buffer, int buflen);

************
File UCNHASH.H
22  int (*_getcode)(const char* name, int namelen, Py_UCS4* 
code);
******
File UCNHASH.H_OLD
22  int (*getcode)(const char* name, int namelen, Py_UCS4* 
code);



I have run the code through a newer version of the compiler
and receive the following messages:

UNICODEDATA:

    if (code < 0 || code >= 65536)
........^
%CC-I-QUESTCOMPARE, In this statement, the unsigned 
expression "code" is being compared with a relational
operator to a constant whose value is not greater than
zero.  This might not be what you intended.
at line number 285 in file UNICODEDATA.C


I guess Frederick is handling this anyway, so excuse me
if I just save a little work on opening another bug report
for this one:

REGEXPR
                        if (ch <= 0 || ch >= RE_NREGS)
............................^
%CC-I-QUESTCOMPARE, In this statement, the unsigned 
expression "ch" is being compared with a relational
operator to a constant whose value is not greater
than zero.  This might not be what you intended.
at line number 1386 in file REGEXPR.C


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

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


From nobody@sourceforge.net  Sun Feb 25 17:20:41 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 25 Feb 2001 09:20:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-232815 ] getname() already in use by OS
Message-ID: <E14X4qf-0002j8-00@usw-sf-web1.sourceforge.net>

Artifact #232815, was updated on 2001-02-17 05:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232815&group_id=5470

Category: Unicode
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Uwe Zessin
Assigned to: Fredrik Lundh
Summary: getname() already in use by OS

Initial Comment:
There is a name-clash on OpenVMS.

modules/unicodedata.c  defines a function named 'getname'.
This collides with a function that is defined in OpenVMS's
include file '<unixio.h>'.

Here is an extract from the documentation:
]getname
]
]   Returns the file specification associated with a file descriptor.
]
]   Format
]
]   #include   <unixio.h>
]
]   char  getname   (int file_desc , char  buffer, . . . );
 [...]
]   Description
]
]   This function places the file specification in the area
] pointed to by buffer and returns that address.  The area
] pointed to by buffer should be an array large enough to
] contain a fully qualified file specification (the maximum
] length is 256 characters).

Note: 'getname' is also used in include/ucnhash.h

I guess that 'getname' does also exist on other operating
systems, but might just be included by a different header
file. Can this be changed, please?


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

Comment By: Fredrik Lundh
Date: 2001-02-25 09:20

Message:
Logged In: YES 
user_id=38376

Umm.  If a global function declaration collides with a
struct member, I'd say you're using a seriously broken
compiler.  What error message do you get?  Are you sure
you've switched on all ANSI compatibility you can get
from your compiler?

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

Comment By: Uwe Zessin
Date: 2001-02-25 07:36

Message:
Logged In: YES 
user_id=155755

The fix is incomplete. For a clean compile I had to change:

File UNICODEOBJECT.C
 1254   if (ucnhash_CAPI->_getcode(start, s-start-1, &chr))
******
File UNICODEOBJECT.C_OLD
 1254   if (ucnhash_CAPI->getcode(start, s-start-1, &chr))

and:

File UCNHASH.H
18  int (*_getname)(Py_UCS4 code, char* buffer, int buflen);
******
File UCNHASH.H_OLD
18  int (*getname)(Py_UCS4 code, char* buffer, int buflen);

************
File UCNHASH.H
22  int (*_getcode)(const char* name, int namelen, Py_UCS4* 
code);
******
File UCNHASH.H_OLD
22  int (*getcode)(const char* name, int namelen, Py_UCS4* 
code);



I have run the code through a newer version of the compiler
and receive the following messages:

UNICODEDATA:

    if (code < 0 || code >= 65536)
........^
%CC-I-QUESTCOMPARE, In this statement, the unsigned 
expression "code" is being compared with a relational
operator to a constant whose value is not greater than
zero.  This might not be what you intended.
at line number 285 in file UNICODEDATA.C


I guess Frederick is handling this anyway, so excuse me
if I just save a little work on opening another bug report
for this one:

REGEXPR
                        if (ch <= 0 || ch >= RE_NREGS)
............................^
%CC-I-QUESTCOMPARE, In this statement, the unsigned 
expression "ch" is being compared with a relational
operator to a constant whose value is not greater
than zero.  This might not be what you intended.
at line number 1386 in file REGEXPR.C


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

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


From nobody@sourceforge.net  Sun Feb 25 19:48:34 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 25 Feb 2001 11:48:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-404130 ] site.py sets sys.path incorrectly.
Message-ID: <E14X79m-00065U-00@usw-sf-web3.sourceforge.net>

Artifact #404130, was updated on 2001-02-25 11:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404130&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Don Rozenberg
Assigned to: Nobody/Anonymous
Summary: site.py sets sys.path incorrectly.

Initial Comment:
site.py appears to append the site-packages to the
END of sys.path.  I think it should be set after 
PYTHONPATH but before the standard places like

'/home/rozen/lib/python2.1',
'/home/rozen/lib/python2.1/plat-linux2',
'/home/rozen/lib/python2.1/lib-tk',
'/home/rozen/lib/python2.1/lib-dynload'.

How else can I install a new version of any of the
packages in the standard places without overwriting
or renaming them.

In particular, I am trying to use disutils to
distribute a version of _tkinter and Tkinter.py; they
get placed in site-packages, which I think is the
correct place, but they don't get executed because the
usual suspects are searched first.

I guess that I can force the issue by setting the
PYTHONPATH, but I don't know how to do that from
distutils.  And that is not an answer.

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

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


From nobody@sourceforge.net  Mon Feb 26 07:23:47 2001
From: nobody@sourceforge.net (nobody)
Date: Sun, 25 Feb 2001 23:23:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-404240 ] time_t  can be unsigned
Message-ID: <E14XI0Z-0002ap-00@usw-sf-web3.sourceforge.net>

Artifact #404240, was updated on 2001-02-25 23:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404240&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Uwe Zessin
Assigned to: Nobody/Anonymous
Summary: time_t  can be unsigned

Initial Comment:
On recent versions of OpenVMS, time_t is defined as:

SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]TIME.H;1

     typedef unsigned long int time_t;


The compiler's complaint is as follows:

        if (mtime == -1)
............^
%CC-I-QUESTCOMPARE1, In this statement, the unsigned
 expression "mtime" is being compared with an equality
 operator to a constant whose value is negative.  This
 might not be what you intended.
at line number 715 in file IMPORT.C


>>> import time
>>> time.ctime(0x7fffffff)
'Tue Jan 19 03:14:07 2038'
>>> time.ctime(0x80000000)
'Tue Jan 19 03:14:08 2038'
>>> time.ctime(0xfffffffe)
'Sun Feb  7 06:28:14 2106'
>>> time.ctime(0xffffffff)
'Sun Feb  7 06:28:15 2106'
>>>


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

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


From nobody@sourceforge.net  Mon Feb 26 13:15:57 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 05:15:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-404277 ] Linking error on AIX (Python 1.5.2)
Message-ID: <E14XNVN-000596-00@usw-sf-web3.sourceforge.net>

Artifact #404277, was updated on 2001-02-26 05:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404277&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Rene Liebscher
Assigned to: Nobody/Anonymous
Summary: Linking error on AIX (Python 1.5.2)

Initial Comment:
The patch from 1.32 to 1.33 of file sysconfig.py
removes some special actions for AIX and BeOS
concerning the paths to the linker scripts.

On Python 1.5.2 these parts are still needed, 
because it doesn't have this new style of Makefile
( LDSHARED and BLDSHARED )

The old version (1.5.2) has no BLDSHARED so if is not
found you could execute the old code to stay
compatible.

Or you declare that Distutils is not suited for
versions <2.X.


Error message (PyOpenGL build):
../././Modules/ld_so_aix cc
build/temp.aix-3-000769244C00-1.5/_openglmodule.o
-L/usr/local/lib -L/usr/X11/lib -L/usr/X11R6/lib
-L/usr/lib -lGL -lX11 -lXext -o
build/lib.aix-3-000769244C00-1.5/OpenGL/dynload/aix4/_opengl.so
unable to execute ../././Modules/ld_so_aix: No such
file or directory
error: command '../././Modules/ld_so_aix' failed with
exit status 1


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

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


From nobody@sourceforge.net  Mon Feb 26 13:16:40 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 05:16:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-404274 ] Linking error on AIX (Python 1.5.2)
Message-ID: <E14XNW4-00059Y-00@usw-sf-web3.sourceforge.net>

Artifact #404274, was updated on 2001-02-26 04:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404274&group_id=5470

Category: Distutils
Group: None
Status: Open
Priority: 5
Submitted By: Rene Liebscher
Assigned to: Nobody/Anonymous
Summary: Linking error on AIX (Python 1.5.2)

Initial Comment:
The patch from 1.32 to 1.33 of file sysconfig.py
removes some special actions for AIX and BeOS
concerning the paths to the linker scripts.

On Python 1.5.2 these parts are still needed, 
because it doesn't have this new style of Makefile
( LDSHARED and BLDSHARED )

The old version (1.5.2) has no BLDSHARED so if is not
found you could execute the old code to stay
compatible.

Or you declare that Distutils is not suited for
versions <2.X.


Error message (PyOpenGL build):
../././Modules/ld_so_aix cc
build/temp.aix-3-000769244C00-1.5/_openglmodule.o
-L/usr/local/lib -L/usr/X11/lib -L/usr/X11R6/lib
-L/usr/lib -lGL -lX11 -lXext -o
build/lib.aix-3-000769244C00-1.5/OpenGL/dynload/aix4/_opengl.so
unable to execute ../././Modules/ld_so_aix: No such
file or directory
error: command '../././Modules/ld_so_aix' failed with
exit status 1


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

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


From nobody@sourceforge.net  Mon Feb 26 13:17:19 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 05:17:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-404277 ] Linking error on AIX (Python 1.5.2)
Message-ID: <E14XNWh-0005A2-00@usw-sf-web3.sourceforge.net>

Artifact #404277, was updated on 2001-02-26 05:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404277&group_id=5470

Category: Distutils
Group: None
Status: Deleted
Priority: 5
Submitted By: Rene Liebscher
Assigned to: Nobody/Anonymous
Summary: Linking error on AIX (Python 1.5.2)

Initial Comment:
The patch from 1.32 to 1.33 of file sysconfig.py
removes some special actions for AIX and BeOS
concerning the paths to the linker scripts.

On Python 1.5.2 these parts are still needed, 
because it doesn't have this new style of Makefile
( LDSHARED and BLDSHARED )

The old version (1.5.2) has no BLDSHARED so if is not
found you could execute the old code to stay
compatible.

Or you declare that Distutils is not suited for
versions <2.X.


Error message (PyOpenGL build):
../././Modules/ld_so_aix cc
build/temp.aix-3-000769244C00-1.5/_openglmodule.o
-L/usr/local/lib -L/usr/X11/lib -L/usr/X11R6/lib
-L/usr/lib -lGL -lX11 -lXext -o
build/lib.aix-3-000769244C00-1.5/OpenGL/dynload/aix4/_opengl.so
unable to execute ../././Modules/ld_so_aix: No such
file or directory
error: command '../././Modules/ld_so_aix' failed with
exit status 1


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

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


From nobody@sourceforge.net  Mon Feb 26 12:53:36 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 04:53:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-404274 ] Linking error on AIX (Python 1.5.2)
Message-ID: <E14XN9k-0004x5-00@usw-sf-web3.sourceforge.net>

Artifact #404274, was updated on 2001-02-26 04:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404274&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Rene Liebscher
Assigned to: Nobody/Anonymous
Summary: Linking error on AIX (Python 1.5.2)

Initial Comment:
The patch from 1.32 to 1.33 of file sysconfig.py
removes some special actions for AIX and BeOS
concerning the paths to the linker scripts.

On Python 1.5.2 these parts are still needed, 
because it doesn't have this new style of Makefile
( LDSHARED and BLDSHARED )

The old version (1.5.2) has no BLDSHARED so if is not
found you could execute the old code to stay
compatible.

Or you declare that Distutils is not suited for
versions <2.X.


Error message (PyOpenGL build):
../././Modules/ld_so_aix cc
build/temp.aix-3-000769244C00-1.5/_openglmodule.o
-L/usr/local/lib -L/usr/X11/lib -L/usr/X11R6/lib
-L/usr/lib -lGL -lX11 -lXext -o
build/lib.aix-3-000769244C00-1.5/OpenGL/dynload/aix4/_opengl.so
unable to execute ../././Modules/ld_so_aix: No such
file or directory
error: command '../././Modules/ld_so_aix' failed with
exit status 1


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

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


From nobody@sourceforge.net  Mon Feb 26 14:38:08 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 06:38:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-232000 ] New robotparser fails for non-HTTP schemes
Message-ID: <E14XOmu-0005sO-00@usw-sf-web3.sourceforge.net>

Artifact #232000, was updated on 2001-02-12 07:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232000&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 7
Submitted By: Fred L. Drake, Jr.
Assigned to: Skip Montanaro
Summary: New robotparser fails for non-HTTP schemes

Initial Comment:
The new robotparser module fails for non-HTTP URLs where the old one did not.  In particular, file: URLs cause an exception to be raised (socket.error: (111, 'Connection refused')) where the old robotparser did not fail.

This is due, at least in part, by the current code using httplib directly rather than using urllib for flexibility.  The code should be changed accordingly.

A good test case for this is running webchecker on a local tree of HTML files.  I currently get the exception:

cj42289-a(.../Doc/html); python ../../Tools/webchecker/webchecker.py -x file://`pwd`/api/
webchecker version 1.22
Traceback (most recent call last):
  File "../../Tools/webchecker/webchecker.py", line 824, in ?
    main()
  File "../../Tools/webchecker/webchecker.py", line 205, in main
    c.addroot(arg)
  File "../../Tools/webchecker/webchecker.py", line 324, in addroot
    self.addrobot(root)
  File "../../Tools/webchecker/webchecker.py", line 337, in addrobot
    rp.read()
  File "/usr/local/lib/python2.1/robotparser.py", line 46, in read
    connection.putrequest("GET", self.path)
  File "/usr/local/lib/python2.1/httplib.py", line 426, in putrequest
    self.send(str)
  File "/usr/local/lib/python2.1/httplib.py", line 368, in send
    self.connect()
  File "/usr/local/lib/python2.1/httplib.py", line 352, in connect
    self.sock.connect((self.host, self.port))
socket.error: (111, 'Connection refused')

Assigned to Skip since he's the robots.txt guru.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-26 06:38

Message:
Logged In: YES 
user_id=3066

Skip, is this fixed now?

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

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


From nobody@sourceforge.net  Mon Feb 26 16:17:31 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 08:17:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-404322 ] Python 2.1a and solaris8/x86
Message-ID: <E14XQL5-0008LK-00@usw-sf-web2.sourceforge.net>

Artifact #404322, was updated on 2001-02-26 08:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404322&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Python 2.1a and solaris8/x86

Initial Comment:
Python 2.1a does not build on Solaris8/X86 with 
gcc 2.95.2 and gmake. The problem has been observed
both with the version of gcc 2.95.2 precompiled from
Sun and with a version bootstrapped on the host where
Python should be built.

'uname -a' says: 
SunOS clutc 5.8 Generic_108529-01 i86pc i386 i86pc

Compilation has been started with
$ ./configure && gmake

The problem occurs in the link step, output is:

gcc   -o python Modules/python.o \
                libpython2.1.a -lpthread -lsocket -lnsl
-ldl  -lthread   -lm  
./python ./setup.py build
Text relocation remains                        
referenced
    against symbol                  offset      in file
_xstat                              0x12       
build/temp.solaris-2.8-i86pc-2.1
/structmodule.o
_lxstat                             0x2a       
build/temp.solaris-2.8-i86pc-2.1
/structmodule.o
_fxstat                             0x42       
build/temp.solaris-2.8-i86pc-2.1
/structmodule.o
_xmknod                             0x5a       
build/temp.solaris-2.8-i86pc-2.1
/structmodule.o
PyInt_AsLong                        0x6e       
build/temp.solaris-2.8-i86pc-2.1
<snip, very long list of similar messages follows,
snip>
ld: fatal: relocations remain against allocatable but
non-writable sections
collect2: ld returned 1 exit status
Text relocation remains                        
referenced
    against symbol                  offset      in file
_xstat                              0x12       
build/temp.solaris-2.8-i86pc-2.1
/regexmodule.o
_xstat                              0x12       
build/temp.solaris-2.8-i86pc-2.1
<again an endless list of similar messages is
following>


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

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


From nobody@sourceforge.net  Mon Feb 26 16:20:28 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 08:20:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-404327 ] struct.calcsize returns wrong size
Message-ID: <E14XQNw-0008Nh-00@usw-sf-web2.sourceforge.net>

Artifact #404327, was updated on 2001-02-26 08:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404327&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: struct.calcsize returns wrong size

Initial Comment:
struct.calcsize returns the wrong size because it takes
into account the alignment of the type.
I needed to read a 56 packed structure and then write
it back.
Python insists that it needs 62 bytes for the fmt
'chl6s20schdhdh'

Using Python-2.1a2 source code I can get the correct
answer by
commenting out in Modules/structmodule.c
        if (e == NULL)
            return -1;
        itemsize = e->size;
-->  //size = align(size, c, e);
        x = num * itemsize; 
        size += x;

Basically packing in a string doesn't require any
alignment. The alignment is neccesary once unpacking
takes place. However if the unpacking is done to a
local c variable then the alignment should not be a
problem e.g.

long Unpack_long(char * offset)
{
long value;
	memcpy(&value,offset,sizeof(long);
	return value;
}

Regards Rene de Zwart

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

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


From nobody@sourceforge.net  Mon Feb 26 16:21:50 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 08:21:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-404328 ] struct.calcsize returns wrong size
Message-ID: <E14XQPG-0000xQ-00@usw-sf-web1.sourceforge.net>

Artifact #404328, was updated on 2001-02-26 08:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404328&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: struct.calcsize returns wrong size

Initial Comment:
struct.calcsize returns the wrong size because it takes
into account the alignment of the type.
I needed to read a 56 packed structure and then write
it back.
Python insists that it needs 62 bytes for the fmt
'chl6s20schdhdh'

Using Python-2.1a2 source code I can get the correct
answer by
commenting out in Modules/structmodule.c
        if (e == NULL)
            return -1;
        itemsize = e->size;
-->  //size = align(size, c, e);
        x = num * itemsize; 
        size += x;

Basically packing in a string doesn't require any
alignment. The alignment is neccesary once unpacking
takes place. However if the unpacking is done to a
local c variable then the alignment should not be a
problem e.g.

long Unpack_long(char * offset)
{
long value;
	memcpy(&value,offset,sizeof(long);
	return value;
}

Regards Rene de Zwart

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

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


From nobody@sourceforge.net  Mon Feb 26 16:24:24 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 08:24:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-404327 ] struct.calcsize returns wrong size
Message-ID: <E14XQRk-00070P-00@usw-sf-web3.sourceforge.net>

Artifact #404327, was updated on 2001-02-26 08:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404327&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: struct.calcsize returns wrong size

Initial Comment:
struct.calcsize returns the wrong size because it takes
into account the alignment of the type.
I needed to read a 56 packed structure and then write
it back.
Python insists that it needs 62 bytes for the fmt
'chl6s20schdhdh'

Using Python-2.1a2 source code I can get the correct
answer by
commenting out in Modules/structmodule.c
        if (e == NULL)
            return -1;
        itemsize = e->size;
-->  //size = align(size, c, e);
        x = num * itemsize; 
        size += x;

Basically packing in a string doesn't require any
alignment. The alignment is neccesary once unpacking
takes place. However if the unpacking is done to a
local c variable then the alignment should not be a
problem e.g.

long Unpack_long(char * offset)
{
long value;
	memcpy(&value,offset,sizeof(long);
	return value;
}

Regards Rene de Zwart

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

Comment By: Nobody/Anonymous
Date: 2001-02-26 08:24

Message:
Logged In: NO 

Oops forgot a test program
#!/usr/bin/python

import struct
  
print " 1 c              ",struct.calcsize('c') 
print " 3 ch             ",struct.calcsize('ch') 
print " 7 chl            ",struct.calcsize('chl') 
print "13 chl6s          ",struct.calcsize('chl6s') 
print "33 chl6s20s       ",struct.calcsize('chl6s20s') 
print "34 chl6s20sc      ",struct.calcsize('chl6s20sc') 
print "36 chl6s20sch     ",struct.calcsize('chl6s20sch') 
print "44 chl6s20schd    ",struct.calcsize('chl6s20schd') 
print "46 chl6s20schdh   ",struct.calcsize('chl6s20schdh') 
print "54 chl6s20schdhd  ",struct.calcsize('chl6s20schdhd') 
print "56 chl6s20schdhdh ",struct.calcsize('chl6s20schdhdh') 

Journaal    = "D"
Periode     = 12
Datum       = 991231
Kode        = "123456"
Titel       = "12345678901234567890"
Klasse      = "H"
HoofdRek    = 1300
HoofdBedrag = 100.97
TegenRek    = 1400
TegenBedrag =-100.97
SubRek      = 2200

data = struct.pack('chl6s20schdhdh',Journaal,Periode,Datum,\
       
Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek)
print
len(data),Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,\
        HoofdBedrag,TegenRek,TegenBedrag,SubRek 


Journaal,   = struct.unpack('c'  ,data[ 0: 1])
Periode,    = struct.unpack('h'  ,data[ 1: 3])
Datum,      = struct.unpack('l'  ,data[ 3: 7])
Kode,       = struct.unpack('6s' ,data[ 7:13])
Titel,      = struct.unpack('20s',data[13:33])
Klasse,     = struct.unpack('c'  ,data[33:34])
HoofdRek,   = struct.unpack('h'  ,data[34:36])
HoofdBedrag,= struct.unpack('d'  ,data[36:44])
TegenRek,   = struct.unpack('h'  ,data[44:46])
TegenBedrag,= struct.unpack('d'  ,data[46:54])
SubRek,     = struct.unpack('h'  ,data[54:56])

Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek,
= struct.unpack('chl6s20schdhdh',data)

print
len(data),Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek 


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

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


From nobody@sourceforge.net  Mon Feb 26 16:25:41 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 08:25:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-404327 ] struct.calcsize returns wrong size
Message-ID: <E14XQSz-00071d-00@usw-sf-web3.sourceforge.net>

Artifact #404327, was updated on 2001-02-26 08:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404327&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: struct.calcsize returns wrong size

Initial Comment:
struct.calcsize returns the wrong size because it takes
into account the alignment of the type.
I needed to read a 56 packed structure and then write
it back.
Python insists that it needs 62 bytes for the fmt
'chl6s20schdhdh'

Using Python-2.1a2 source code I can get the correct
answer by
commenting out in Modules/structmodule.c
        if (e == NULL)
            return -1;
        itemsize = e->size;
-->  //size = align(size, c, e);
        x = num * itemsize; 
        size += x;

Basically packing in a string doesn't require any
alignment. The alignment is neccesary once unpacking
takes place. However if the unpacking is done to a
local c variable then the alignment should not be a
problem e.g.

long Unpack_long(char * offset)
{
long value;
	memcpy(&value,offset,sizeof(long);
	return value;
}

Regards Rene de Zwart

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

Comment By: Nobody/Anonymous
Date: 2001-02-26 08:25

Message:
Logged In: NO 

Oops forgot a test program
#!/usr/bin/python

import struct
  
print " 1 c              ",struct.calcsize('c') 
print " 3 ch             ",struct.calcsize('ch') 
print " 7 chl            ",struct.calcsize('chl') 
print "13 chl6s          ",struct.calcsize('chl6s') 
print "33 chl6s20s       ",struct.calcsize('chl6s20s') 
print "34 chl6s20sc      ",struct.calcsize('chl6s20sc') 
print "36 chl6s20sch     ",struct.calcsize('chl6s20sch') 
print "44 chl6s20schd    ",struct.calcsize('chl6s20schd') 
print "46 chl6s20schdh   ",struct.calcsize('chl6s20schdh') 
print "54 chl6s20schdhd  ",struct.calcsize('chl6s20schdhd') 
print "56 chl6s20schdhdh ",struct.calcsize('chl6s20schdhdh') 

Journaal    = "D"
Periode     = 12
Datum       = 991231
Kode        = "123456"
Titel       = "12345678901234567890"
Klasse      = "H"
HoofdRek    = 1300
HoofdBedrag = 100.97
TegenRek    = 1400
TegenBedrag =-100.97
SubRek      = 2200

data = struct.pack('chl6s20schdhdh',Journaal,Periode,Datum,\
       
Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek)
print
len(data),Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,\
        HoofdBedrag,TegenRek,TegenBedrag,SubRek 


Journaal,   = struct.unpack('c'  ,data[ 0: 1])
Periode,    = struct.unpack('h'  ,data[ 1: 3])
Datum,      = struct.unpack('l'  ,data[ 3: 7])
Kode,       = struct.unpack('6s' ,data[ 7:13])
Titel,      = struct.unpack('20s',data[13:33])
Klasse,     = struct.unpack('c'  ,data[33:34])
HoofdRek,   = struct.unpack('h'  ,data[34:36])
HoofdBedrag,= struct.unpack('d'  ,data[36:44])
TegenRek,   = struct.unpack('h'  ,data[44:46])
TegenBedrag,= struct.unpack('d'  ,data[46:54])
SubRek,     = struct.unpack('h'  ,data[54:56])

Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek,
= struct.unpack('chl6s20schdhdh',data)

print
len(data),Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek 


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

Comment By: Nobody/Anonymous
Date: 2001-02-26 08:24

Message:
Logged In: NO 

Oops forgot a test program
#!/usr/bin/python

import struct
  
print " 1 c              ",struct.calcsize('c') 
print " 3 ch             ",struct.calcsize('ch') 
print " 7 chl            ",struct.calcsize('chl') 
print "13 chl6s          ",struct.calcsize('chl6s') 
print "33 chl6s20s       ",struct.calcsize('chl6s20s') 
print "34 chl6s20sc      ",struct.calcsize('chl6s20sc') 
print "36 chl6s20sch     ",struct.calcsize('chl6s20sch') 
print "44 chl6s20schd    ",struct.calcsize('chl6s20schd') 
print "46 chl6s20schdh   ",struct.calcsize('chl6s20schdh') 
print "54 chl6s20schdhd  ",struct.calcsize('chl6s20schdhd') 
print "56 chl6s20schdhdh ",struct.calcsize('chl6s20schdhdh') 

Journaal    = "D"
Periode     = 12
Datum       = 991231
Kode        = "123456"
Titel       = "12345678901234567890"
Klasse      = "H"
HoofdRek    = 1300
HoofdBedrag = 100.97
TegenRek    = 1400
TegenBedrag =-100.97
SubRek      = 2200

data = struct.pack('chl6s20schdhdh',Journaal,Periode,Datum,\
       
Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek)
print
len(data),Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,\
        HoofdBedrag,TegenRek,TegenBedrag,SubRek 


Journaal,   = struct.unpack('c'  ,data[ 0: 1])
Periode,    = struct.unpack('h'  ,data[ 1: 3])
Datum,      = struct.unpack('l'  ,data[ 3: 7])
Kode,       = struct.unpack('6s' ,data[ 7:13])
Titel,      = struct.unpack('20s',data[13:33])
Klasse,     = struct.unpack('c'  ,data[33:34])
HoofdRek,   = struct.unpack('h'  ,data[34:36])
HoofdBedrag,= struct.unpack('d'  ,data[36:44])
TegenRek,   = struct.unpack('h'  ,data[44:46])
TegenBedrag,= struct.unpack('d'  ,data[46:54])
SubRek,     = struct.unpack('h'  ,data[54:56])

Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek,
= struct.unpack('chl6s20schdhdh',data)

print
len(data),Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek 


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

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


From nobody@sourceforge.net  Mon Feb 26 17:01:43 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 09:01:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-232000 ] New robotparser fails for non-HTTP schemes
Message-ID: <E14XR1r-0001Rg-00@usw-sf-web1.sourceforge.net>

Artifact #232000, was updated on 2001-02-12 07:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232000&group_id=5470

Category: Python Library
Group: None
Status: Closed
Priority: 7
Submitted By: Fred L. Drake, Jr.
Assigned to: Skip Montanaro
Summary: New robotparser fails for non-HTTP schemes

Initial Comment:
The new robotparser module fails for non-HTTP URLs where the old one did not.  In particular, file: URLs cause an exception to be raised (socket.error: (111, 'Connection refused')) where the old robotparser did not fail.

This is due, at least in part, by the current code using httplib directly rather than using urllib for flexibility.  The code should be changed accordingly.

A good test case for this is running webchecker on a local tree of HTML files.  I currently get the exception:

cj42289-a(.../Doc/html); python ../../Tools/webchecker/webchecker.py -x file://`pwd`/api/
webchecker version 1.22
Traceback (most recent call last):
  File "../../Tools/webchecker/webchecker.py", line 824, in ?
    main()
  File "../../Tools/webchecker/webchecker.py", line 205, in main
    c.addroot(arg)
  File "../../Tools/webchecker/webchecker.py", line 324, in addroot
    self.addrobot(root)
  File "../../Tools/webchecker/webchecker.py", line 337, in addrobot
    rp.read()
  File "/usr/local/lib/python2.1/robotparser.py", line 46, in read
    connection.putrequest("GET", self.path)
  File "/usr/local/lib/python2.1/httplib.py", line 426, in putrequest
    self.send(str)
  File "/usr/local/lib/python2.1/httplib.py", line 368, in send
    self.connect()
  File "/usr/local/lib/python2.1/httplib.py", line 352, in connect
    self.sock.connect((self.host, self.port))
socket.error: (111, 'Connection refused')

Assigned to Skip since he's the robots.txt guru.

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

Comment By: Skip Montanaro
Date: 2001-02-26 09:01

Message:
Logged In: YES 
user_id=44345

Yes, my apologies.  Fixed by version 1.9.


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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-26 06:38

Message:
Logged In: YES 
user_id=3066

Skip, is this fixed now?

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

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


From nobody@sourceforge.net  Mon Feb 26 17:14:59 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 09:14:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-404327 ] struct.calcsize returns wrong size
Message-ID: <E14XREh-0000Pv-00@usw-sf-web2.sourceforge.net>

Artifact #404327, was updated on 2001-02-26 08:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404327&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Guido van Rossum
Summary: struct.calcsize returns wrong size

Initial Comment:
struct.calcsize returns the wrong size because it takes
into account the alignment of the type.
I needed to read a 56 packed structure and then write
it back.
Python insists that it needs 62 bytes for the fmt
'chl6s20schdhdh'

Using Python-2.1a2 source code I can get the correct
answer by
commenting out in Modules/structmodule.c
        if (e == NULL)
            return -1;
        itemsize = e->size;
-->  //size = align(size, c, e);
        x = num * itemsize; 
        size += x;

Basically packing in a string doesn't require any
alignment. The alignment is neccesary once unpacking
takes place. However if the unpacking is done to a
local c variable then the alignment should not be a
problem e.g.

long Unpack_long(char * offset)
{
long value;
	memcpy(&value,offset,sizeof(long);
	return value;
}

Regards Rene de Zwart

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

Comment By: Guido van Rossum
Date: 2001-02-26 09:14

Message:
Logged In: YES 
user_id=6380

Are you sure this structure corresponds to a C structure?

You are using the format with the default mode, which
calculates
alignments according to the rules for C structures.

I'm betting that your structure is read from a file, and is
unaligned.

If I use this format, '<chl6s20schdhdh', I get a length of
56.

I'm closing the bug report now.

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

Comment By: Nobody/Anonymous
Date: 2001-02-26 08:25

Message:
Logged In: NO 

Oops forgot a test program
#!/usr/bin/python

import struct
  
print " 1 c              ",struct.calcsize('c') 
print " 3 ch             ",struct.calcsize('ch') 
print " 7 chl            ",struct.calcsize('chl') 
print "13 chl6s          ",struct.calcsize('chl6s') 
print "33 chl6s20s       ",struct.calcsize('chl6s20s') 
print "34 chl6s20sc      ",struct.calcsize('chl6s20sc') 
print "36 chl6s20sch     ",struct.calcsize('chl6s20sch') 
print "44 chl6s20schd    ",struct.calcsize('chl6s20schd') 
print "46 chl6s20schdh   ",struct.calcsize('chl6s20schdh') 
print "54 chl6s20schdhd  ",struct.calcsize('chl6s20schdhd') 
print "56 chl6s20schdhdh ",struct.calcsize('chl6s20schdhdh') 

Journaal    = "D"
Periode     = 12
Datum       = 991231
Kode        = "123456"
Titel       = "12345678901234567890"
Klasse      = "H"
HoofdRek    = 1300
HoofdBedrag = 100.97
TegenRek    = 1400
TegenBedrag =-100.97
SubRek      = 2200

data = struct.pack('chl6s20schdhdh',Journaal,Periode,Datum,\
       
Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek)
print
len(data),Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,\
        HoofdBedrag,TegenRek,TegenBedrag,SubRek 


Journaal,   = struct.unpack('c'  ,data[ 0: 1])
Periode,    = struct.unpack('h'  ,data[ 1: 3])
Datum,      = struct.unpack('l'  ,data[ 3: 7])
Kode,       = struct.unpack('6s' ,data[ 7:13])
Titel,      = struct.unpack('20s',data[13:33])
Klasse,     = struct.unpack('c'  ,data[33:34])
HoofdRek,   = struct.unpack('h'  ,data[34:36])
HoofdBedrag,= struct.unpack('d'  ,data[36:44])
TegenRek,   = struct.unpack('h'  ,data[44:46])
TegenBedrag,= struct.unpack('d'  ,data[46:54])
SubRek,     = struct.unpack('h'  ,data[54:56])

Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek,
= struct.unpack('chl6s20schdhdh',data)

print
len(data),Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek 


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

Comment By: Nobody/Anonymous
Date: 2001-02-26 08:24

Message:
Logged In: NO 

Oops forgot a test program
#!/usr/bin/python

import struct
  
print " 1 c              ",struct.calcsize('c') 
print " 3 ch             ",struct.calcsize('ch') 
print " 7 chl            ",struct.calcsize('chl') 
print "13 chl6s          ",struct.calcsize('chl6s') 
print "33 chl6s20s       ",struct.calcsize('chl6s20s') 
print "34 chl6s20sc      ",struct.calcsize('chl6s20sc') 
print "36 chl6s20sch     ",struct.calcsize('chl6s20sch') 
print "44 chl6s20schd    ",struct.calcsize('chl6s20schd') 
print "46 chl6s20schdh   ",struct.calcsize('chl6s20schdh') 
print "54 chl6s20schdhd  ",struct.calcsize('chl6s20schdhd') 
print "56 chl6s20schdhdh ",struct.calcsize('chl6s20schdhdh') 

Journaal    = "D"
Periode     = 12
Datum       = 991231
Kode        = "123456"
Titel       = "12345678901234567890"
Klasse      = "H"
HoofdRek    = 1300
HoofdBedrag = 100.97
TegenRek    = 1400
TegenBedrag =-100.97
SubRek      = 2200

data = struct.pack('chl6s20schdhdh',Journaal,Periode,Datum,\
       
Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek)
print
len(data),Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,\
        HoofdBedrag,TegenRek,TegenBedrag,SubRek 


Journaal,   = struct.unpack('c'  ,data[ 0: 1])
Periode,    = struct.unpack('h'  ,data[ 1: 3])
Datum,      = struct.unpack('l'  ,data[ 3: 7])
Kode,       = struct.unpack('6s' ,data[ 7:13])
Titel,      = struct.unpack('20s',data[13:33])
Klasse,     = struct.unpack('c'  ,data[33:34])
HoofdRek,   = struct.unpack('h'  ,data[34:36])
HoofdBedrag,= struct.unpack('d'  ,data[36:44])
TegenRek,   = struct.unpack('h'  ,data[44:46])
TegenBedrag,= struct.unpack('d'  ,data[46:54])
SubRek,     = struct.unpack('h'  ,data[54:56])

Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek,
= struct.unpack('chl6s20schdhdh',data)

print
len(data),Journaal,Periode,Datum,Kode,Titel,Klasse,HoofdRek,HoofdBedrag,TegenRek,TegenBedrag,SubRek 


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

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


From nobody@sourceforge.net  Mon Feb 26 17:43:06 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 09:43:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-227562 ] variable return from urllib.FancyURLopener.http_error_401
Message-ID: <E14XRfu-0007ff-00@usw-sf-web3.sourceforge.net>

Artifact #227562, was updated on 2001-01-04 11:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227562&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Skip Montanaro
Assigned to: Moshe Zadka
Summary: variable return from urllib.FancyURLopener.http_error_401

Initial Comment:
The block structure in urllib.FancyURLopener.http_error_401 suggests that there are cases where it can return None or the result of retrying basic http/https authentication.  It seems to me that either you should assume that the response headers will always have valid contents (a www-authenticate of the proper format) or do something in the case where they don't (perhaps raise an exception).  I suspect all you'd be doing is protecting the application against a broken server, but I think those cases should still be handled.


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

Comment By: Fred L. Drake, Jr.
Date: 2001-01-07 15:31

Message:
Assigned to Jeremy since he likes to play with urllib.  ;-)

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

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


From nobody@sourceforge.net  Mon Feb 26 19:17:18 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 11:17:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-233665 ] Race condition in threading (Conditions)
Message-ID: <E14XT94-0003F2-00@usw-sf-web1.sourceforge.net>

Artifact #233665, was updated on 2001-02-22 13:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233665&group_id=5470

Category: Threads
Group: Not a Bug
Status: Closed
Priority: 4
Submitted By: Nobody/Anonymous
Assigned to: Tim Peters
Summary: Race condition in threading (Conditions)

Initial Comment:
Here is a race condition involving a _Condition() object cond and a predicate called condition.

Thread A executes:
	cond.acquire()
	while not condition:
		cond.wait() <--

A goes into wait():
	waiter = _allocate_lock()
	waiter.acquire()
	self.__waiters.append(waiter)
	saved_state = self._release_save() <--

A finishes that last line and is interrupted by Thread B. A has released cond's lock, so B continues (who was previously blocked at cond.acquire()):
	cond.acquire()
	condition = 1
	cond.notifyAll()
	cond.release()

Back to A:
	if timeout is None:
		waiter.acquire() <--

A blocks here and completely misses the notifyAll() call. Even though it called wait() before notifyAll(), it will now wait indefinatly for the next notify()/notifyAll() call (which may be never).
I have run into this thread race bug in my program several times. A POSIX-like atomic operation that releases a mutex and then grabs another would be very useful here. Any suggestions?


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

Comment By: Tim Peters
Date: 2001-02-26 11:17

Message:
Logged In: YES 
user_id=31435

Closing as NotABug in the absence of more info, as 
explained in the followup 3 days ago.

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

Comment By: Tim Peters
Date: 2001-02-23 00:11

Message:
You're going to have to work a lot harder to convince me that A can block.  When cond.notifyAll() is executed, *all* the waiters in self.__waiters get released.  It's certain that the waiter W allocated by A is in self.__waiters at that point, because the append of W was protected by the condvar lock, and B can't do cond.notifyAll() before it does cond.acquire().

Therefore W is in self.__waiters when cond.notifyAll() is executed; therefore cond.notifyAll()'s

for waiter in waiters: waiter.release()

executes W.release() in particular; therefore A's W.acquire() succeeds sooner or later after that.

IOW, A cannot block on waiter.acquire(), because notifyAll() does waiter.release().

I agree this *would* be a bug if A could block here, but, as above, I see no reason to believe that it can.

Have reduced priority, and will close as NotABug tomorrow in the absence of more info.

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

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


From nobody@sourceforge.net  Mon Feb 26 20:53:49 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 12:53:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-404322 ] Python 2.1a and solaris8/x86
Message-ID: <E14XUeT-0004QE-00@usw-sf-web1.sourceforge.net>

Artifact #404322, was updated on 2001-02-26 08:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404322&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Python 2.1a and solaris8/x86

Initial Comment:
Python 2.1a does not build on Solaris8/X86 with 
gcc 2.95.2 and gmake. The problem has been observed
both with the version of gcc 2.95.2 precompiled from
Sun and with a version bootstrapped on the host where
Python should be built.

'uname -a' says: 
SunOS clutc 5.8 Generic_108529-01 i86pc i386 i86pc

Compilation has been started with
$ ./configure && gmake

The problem occurs in the link step, output is:

gcc   -o python Modules/python.o \
                libpython2.1.a -lpthread -lsocket -lnsl
-ldl  -lthread   -lm  
./python ./setup.py build
Text relocation remains                        
referenced
    against symbol                  offset      in file
_xstat                              0x12       
build/temp.solaris-2.8-i86pc-2.1
/structmodule.o
_lxstat                             0x2a       
build/temp.solaris-2.8-i86pc-2.1
/structmodule.o
_fxstat                             0x42       
build/temp.solaris-2.8-i86pc-2.1
/structmodule.o
_xmknod                             0x5a       
build/temp.solaris-2.8-i86pc-2.1
/structmodule.o
PyInt_AsLong                        0x6e       
build/temp.solaris-2.8-i86pc-2.1
<snip, very long list of similar messages follows,
snip>
ld: fatal: relocations remain against allocatable but
non-writable sections
collect2: ld returned 1 exit status
Text relocation remains                        
referenced
    against symbol                  offset      in file
_xstat                              0x12       
build/temp.solaris-2.8-i86pc-2.1
/regexmodule.o
_xstat                              0x12       
build/temp.solaris-2.8-i86pc-2.1
<again an endless list of similar messages is
following>


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

Comment By: Samuele Pedroni
Date: 2001-02-26 12:53

Message:
Logged In: YES 
user_id=61408

same true under SPARC.

The problem is that with the default settings gcc -shared
passes '-z text' to ld.
I don't know if the corresponding test make sense.
OTOH the option -mimpure-text makes things work (? =text
sects writable)
Need  .so  to have writable text sections or is gcc doing
something
wrong passing the -z text option down to ld? ...

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

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


From nobody@sourceforge.net  Mon Feb 26 21:56:57 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 13:56:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-232913 ] ConfigParser set() does not xform option
Message-ID: <E14XVdZ-0005AV-00@usw-sf-web1.sourceforge.net>

Artifact #232913, was updated on 2001-02-17 21:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232913&group_id=5470

Category: Python Library
Group: None
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Fred L. Drake, Jr.
Summary: ConfigParser set() does not xform option

Initial Comment:
ConfigParser's set(section,option,value) does not optionxform the option when adding it to the section.  This is not consistent with what happens from read().

Fix: add option=self.optionxform(option) at beginning of set()


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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-26 13:56

Message:
Logged In: YES 
user_id=3066

Fixed in Lib/ConfigParser.py revision 1.32.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-19 13:42

Message:
has_option(), set(), and remove_option() all exhibit this issue.  I'll check in the fix once I've written some test cases that deal with this.

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

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


From nobody@sourceforge.net  Mon Feb 26 23:46:21 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 15:46:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-404444 ] auto indent/parentheses
Message-ID: <E14XXLR-0002Ty-00@usw-sf-web3.sourceforge.net>

Artifact #404444, was updated on 2001-02-26 15:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404444&group_id=5470

Category: IDLE
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Charles Doutriaux
Assigned to: Nobody/Anonymous
Summary: auto indent/parentheses

Initial Comment:
It'd be really nice to have an automatic indent of a
line when using the "TAB" key anywhere on the line,
this feature exist in the python emacs mode and is
REALLY nice and a total time-saver.
Also, having the possibility to see which
parentheses/brackets you're closing while typing (as in
a lot of editors) would be really nice

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

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


From nobody@sourceforge.net  Tue Feb 27 03:49:26 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 19:49:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-229718 ] file locking lossage
Message-ID: <E14Xb8g-0004Ny-00@usw-sf-web3.sourceforge.net>

Artifact #229718, was updated on 2001-01-22 12:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=229718&group_id=5470

Category: Python Library
Group: None
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Barry Warsaw
Summary: file locking lossage

Initial Comment:
(reference:
http://www.erlenstar.demon.co.uk/unix/faq_3.html#SEC35)

there are 4 ways to lock a file in unix.
fcntl, lockf, flock and dotlocking.

the only portable ways are fcntl and dotfiles. dotlocking
is more nfs-resistant. (actually the only reliable
nfs-resistant way seems to be a combination.
see eg. http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=43491)

both fcntl and dotlock require magic incantations to
implement. therefore it is desireable to include code
to do this in the standard python library.

there is only one module in the python distribution
that implements dot-locking or fcntl() locking:
the posixfile module.

however, it is marked as obsolete(!) because someone
misguidedly thinked the sysv lockf is more portable.

this leads to a situation where the most sensible
low-effort way to implement file locking is to
either cut-n-paste code from the posixfile module,
or to call an external program (such as lockfile(1)
from the procmail package) to do it.

  -- Erno Kuusela
     erno@iki.fi


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

Comment By: Nobody/Anonymous
Date: 2001-02-26 19:49

Message:
Logged In: NO 

premise:

- fcntl should be used for locking, not fcntl or lockf,
because of protability
- it requires building a struct whose format is platform
  specific

if so, the posixfile (or equivalent)
functionality is needed for the foreseeable future.


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

Comment By: Barry Warsaw
Date: 2001-02-23 11:44

Message:
I'm not entirely sure what the bug is that you're reporting.  
Are you saying that posixfile should not be marked as obsolete?  I recently made some minor changes (docs and symbols) to fcntl to make lockf more understandable.

IMO, file locking is so application and platform dependent that it isn't very useful to have higher level modules available in the standard library.  E.g., I have a LockFile module in Mailman which is nfs-resistant, but also supports lock breaking semantics (at the expense of occasionally stale locks).

Thus, I think the posixfile documentation is fine, and lockf is useful in some situations (and does work fine, at least on Linux).  So I think there is no bug here.  If you disagree, and think posixfile should not be marked as obsolete, please follow up to this comment and I'll reassign to Fred.

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

Comment By: Donn Cave
Date: 2001-02-08 12:55

Message:
It isn't the prettiest thing in Python, but
I wouldn't have thought fcntl.lockf() would
be such a problem.  I get lockf() even on Ultrix!
In every case I can find, it's implemented per
X/Open to make the same locks as fcntl(), so the
choice between one or the other is only API.
Is it worse than I know?  (I'm just a mildly
interested member of the general Python user
public, not speaking for anyone.)

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

Comment By: Fred L. Drake, Jr.
Date: 2001-01-26 10:28

Message:
Assigned to Barry, since he deals with file locking the most these days.

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

Comment By: Nobody/Anonymous
Date: 2001-01-22 13:25

Message:
(i apologise for the irritated tone of the above
report.)

it apperas the approach used in posixfile is not so bullet-proof either. in addition of the layout of the flock struct being platform-dependent,
it is also (at least on linux) dependent also
of the compilation mode used. if python
is compiled with a 64-bit file offsets,
the start and len members can grow in size.
so this would either need to be done in c code
or the code should test for the file offset
size (i don't know if it's possible to find this
out in python code).

  -- erno

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

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


From nobody@sourceforge.net  Tue Feb 27 04:13:18 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 20:13:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-230029 ] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E14XbVm-0000xT-00@usw-sf-web1.sourceforge.net>

Artifact #230029, was updated on 2001-01-25 02:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230029&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Guido van Rossum
Summary: [HP-UX] Python chokes on pthread_mutex_init

Initial Comment:
On an HPUX 11.00:  During "make intstall":

./install-sh -c -m 644 ./Lib/curses/__init__.py /opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/ascii.py /opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/has_key.py /opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/textpad.py /opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/wrapper.py /opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/plat-hp-uxB/core /opt/tmp/Python/lib/python2.0/plat-hp-uxB
./install-sh -c -m 755 ./Lib/plat-hp-uxB/regen /opt/tmp/Python/lib/python2.0/plat-hp-uxB
        ./install-sh -c -m 644 ./LICENSE /opt/tmp/Python/lib/python2.0/LICENSE.txt
        PYTHONPATH=/opt/tmp/Python/lib/python2.0 \
                        ./python -tt /opt/tmp/Python/lib/python2.0/compileall.py /opt/tmp/Python/lib/python2.0
pthread_mutex_init: Invalid argument
sh: 6074 Memory fault(coredump)

----------------------------------------------------------
This fault can be reproduced:

export PYTHONPATH=/opt/tmp/Python/lib/python2.0

/opt/stephie/Python-2.0 > ./python -tt /opt/tmp/Python/lib/python2.0/compileall.py /opt/tmp/Python/lib/python2.0
pthread_mutex_init: Invalid argument
Memory fault(coredump)



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

Comment By: Todd Whiteman
Date: 2001-02-26 20:13

Message:
Logged In: YES 
user_id=149041

This works for me on HPUX-11:

Open the Modules/Makefile and change the following line:
LIBS= -lnsl -ldld -lcma
to the following
LIBS= -lnsl -ldld -lpthread -lcl

rm Modules/threadmodule.o
make


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

Comment By: Tim Peters
Date: 2001-02-09 15:29

Message:
Assigned to our resident HP-UX fan <wink>.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-01 12:10

Message:
This may be the same bug as #110650 (already closed, but not clear that this was ever actually fixed).

Too bad this was an anonymous report; we can't ask for more information without an email address.

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

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


From nobody@sourceforge.net  Tue Feb 27 05:20:16 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 21:20:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-233532 ] Add warning about undefined "global"
Message-ID: <E14XcYa-0006FV-00@usw-sf-web2.sourceforge.net>

Artifact #233532, was updated on 2001-02-21 18:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233532&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Priority: 7
Submitted By: Tim Peters
Assigned to: Jeremy Hylton
Summary: Add warning about undefined "global"

Initial Comment:
The Ref Man has always said that "global" must not be used in some contexts, but that this was currently unenforced.  We should warn about this stuff in 2.1, so we can make it an error in a future release.

Example:

def f():
    g = 1
    global g

def f():
    print g
    global g


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

Comment By: Jeremy Hylton
Date: 2001-02-26 21:20

Message:
Logged In: YES 
user_id=31392

added in rev 2.173 of compile.c


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

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


From nobody@sourceforge.net  Tue Feb 27 05:20:26 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 21:20:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-233532 ] Add warning about undefined "global"
Message-ID: <E14XcYk-0006Fl-00@usw-sf-web2.sourceforge.net>

Artifact #233532, was updated on 2001-02-21 18:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=233532&group_id=5470

Category: Parser/Compiler
Group: None
Status: Closed
Priority: 7
Submitted By: Tim Peters
Assigned to: Jeremy Hylton
Summary: Add warning about undefined "global"

Initial Comment:
The Ref Man has always said that "global" must not be used in some contexts, but that this was currently unenforced.  We should warn about this stuff in 2.1, so we can make it an error in a future release.

Example:

def f():
    g = 1
    global g

def f():
    print g
    global g


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

Comment By: Jeremy Hylton
Date: 2001-02-26 21:20

Message:
Logged In: YES 
user_id=31392

added in rev 2.173 of compile.c


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

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


From nobody@sourceforge.net  Tue Feb 27 07:29:09 2001
From: nobody@sourceforge.net (nobody)
Date: Mon, 26 Feb 2001 23:29:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-227562 ] variable return from urllib.FancyURLopener.http_error_401
Message-ID: <E14XeZJ-0002tR-00@usw-sf-web1.sourceforge.net>

Artifact #227562, was updated on 2001-01-04 11:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=227562&group_id=5470

Category: Python Library
Group: None
Status: Closed
Priority: 5
Submitted By: Skip Montanaro
Assigned to: Moshe Zadka
Summary: variable return from urllib.FancyURLopener.http_error_401

Initial Comment:
The block structure in urllib.FancyURLopener.http_error_401 suggests that there are cases where it can return None or the result of retrying basic http/https authentication.  It seems to me that either you should assume that the response headers will always have valid contents (a www-authenticate of the proper format) or do something in the case where they don't (perhaps raise an exception).  I suspect all you'd be doing is protecting the application against a broken server, but I think those cases should still be handled.


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

Comment By: Moshe Zadka
Date: 2001-02-26 23:29

Message:
Logged In: YES 
user_id=11645

Fixed in urllib.py v 1.118 -- now calls
URLopener.http_error_default in such cases

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

Comment By: Fred L. Drake, Jr.
Date: 2001-01-07 15:31

Message:
Assigned to Jeremy since he likes to play with urllib.  ;-)

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

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


From nobody@sourceforge.net  Tue Feb 27 09:06:18 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 01:06:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-404535 ] Bug in ConfigParser.py
Message-ID: <E14Xg5K-0007oC-00@usw-sf-web2.sourceforge.net>

Artifact #404535, was updated on 2001-02-27 01:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404535&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Bug in ConfigParser.py

Initial Comment:
One problem is that both get() and read() switch the 
options to lower case (using 
ConfigParser.optionxform), but NONE of the other 
methods do this.
Basically what this means is that ConfigParser only 
works if you don't use any upper case in your option 
names, or you only use read() and get().

Another bug is in the remove_option() function.
It seams to me that there is a unreferenced 
variable "key".

Source code from ConfigParser.remove_option()

existed = sectdict.has_key(key)
        if existed:
            del sectdict[key]

To be able to use the function remove_option(), I had 
to change the variable "key" to "option" which is 
declared in the function header like this:

existed = sectdict.has_key(option)
        if existed:
            del sectdict[option]

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

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


From nobody@sourceforge.net  Tue Feb 27 09:07:30 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 01:07:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-404536 ] Bug in ConfigParser.py
Message-ID: <E14Xg6U-0006ba-00@usw-sf-web3.sourceforge.net>

Artifact #404536, was updated on 2001-02-27 01:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404536&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Bug in ConfigParser.py

Initial Comment:
One problem is that both get() and read() switch the 
options to lower case (using 
ConfigParser.optionxform), but NONE of the other 
methods do this.
Basically what this means is that ConfigParser only 
works if you don't use any upper case in your option 
names, or you only use read() and get().

Another bug is in the remove_option() function.
It seams to me that there is a unreferenced 
variable "key".

Source code from ConfigParser.remove_option()

existed = sectdict.has_key(key)
        if existed:
            del sectdict[key]

To be able to use the function remove_option(), I had 
to change the variable "key" to "option" which is 
declared in the function header like this:

existed = sectdict.has_key(option)
        if existed:
            del sectdict[option]

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

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


From nobody@sourceforge.net  Tue Feb 27 09:13:20 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 01:13:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-232815 ] getname() already in use by OS
Message-ID: <E14XgC8-0006ec-00@usw-sf-web3.sourceforge.net>

Artifact #232815, was updated on 2001-02-17 05:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232815&group_id=5470

Category: Unicode
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Uwe Zessin
Assigned to: Fredrik Lundh
Summary: getname() already in use by OS

Initial Comment:
There is a name-clash on OpenVMS.

modules/unicodedata.c  defines a function named 'getname'.
This collides with a function that is defined in OpenVMS's
include file '<unixio.h>'.

Here is an extract from the documentation:
]getname
]
]   Returns the file specification associated with a file descriptor.
]
]   Format
]
]   #include   <unixio.h>
]
]   char  getname   (int file_desc , char  buffer, . . . );
 [...]
]   Description
]
]   This function places the file specification in the area
] pointed to by buffer and returns that address.  The area
] pointed to by buffer should be an array large enough to
] contain a fully qualified file specification (the maximum
] length is 256 characters).

Note: 'getname' is also used in include/ucnhash.h

I guess that 'getname' does also exist on other operating
systems, but might just be included by a different header
file. Can this be changed, please?


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

Comment By: Uwe Zessin
Date: 2001-02-27 01:13

Message:
Logged In: YES 
user_id=155755

Oops. I've raised a false alarm for UCNHASH.H +
UNICODEOBJECT.C, sorry. The problem was that I
patched UCNHASH.H again.

I think the Compaq C/ DEC C compilers are quite
good - I have to blame myself :-(

However, the compiler's complains for UNICODEDATA.C
and REGEXPR.C is still valid - shold we close this
and open another report for them?

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

Comment By: Fredrik Lundh
Date: 2001-02-25 09:20

Message:
Logged In: YES 
user_id=38376

Umm.  If a global function declaration collides with a
struct member, I'd say you're using a seriously broken
compiler.  What error message do you get?  Are you sure
you've switched on all ANSI compatibility you can get
from your compiler?

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

Comment By: Uwe Zessin
Date: 2001-02-25 07:36

Message:
Logged In: YES 
user_id=155755

The fix is incomplete. For a clean compile I had to change:

File UNICODEOBJECT.C
 1254   if (ucnhash_CAPI->_getcode(start, s-start-1, &chr))
******
File UNICODEOBJECT.C_OLD
 1254   if (ucnhash_CAPI->getcode(start, s-start-1, &chr))

and:

File UCNHASH.H
18  int (*_getname)(Py_UCS4 code, char* buffer, int buflen);
******
File UCNHASH.H_OLD
18  int (*getname)(Py_UCS4 code, char* buffer, int buflen);

************
File UCNHASH.H
22  int (*_getcode)(const char* name, int namelen, Py_UCS4* 
code);
******
File UCNHASH.H_OLD
22  int (*getcode)(const char* name, int namelen, Py_UCS4* 
code);



I have run the code through a newer version of the compiler
and receive the following messages:

UNICODEDATA:

    if (code < 0 || code >= 65536)
........^
%CC-I-QUESTCOMPARE, In this statement, the unsigned 
expression "code" is being compared with a relational
operator to a constant whose value is not greater than
zero.  This might not be what you intended.
at line number 285 in file UNICODEDATA.C


I guess Frederick is handling this anyway, so excuse me
if I just save a little work on opening another bug report
for this one:

REGEXPR
                        if (ch <= 0 || ch >= RE_NREGS)
............................^
%CC-I-QUESTCOMPARE, In this statement, the unsigned 
expression "ch" is being compared with a relational
operator to a constant whose value is not greater
than zero.  This might not be what you intended.
at line number 1386 in file REGEXPR.C


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

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


From nobody@sourceforge.net  Tue Feb 27 09:15:16 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 01:15:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-404539 ] os.listdir() can't grok Unicode filename
Message-ID: <E14XgE0-0006fd-00@usw-sf-web3.sourceforge.net>

Artifact #404539, was updated on 2001-02-27 01:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404539&group_id=5470

Category: Unicode
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Itamar S.T.
Assigned to: Nobody/Anonymous
Summary: os.listdir() can't grok Unicode filename

Initial Comment:
I have a file whose name is part Hebrew, part English
on my W2K VMware install. Filenames on Win2000 are
Unicode, if I'm not mistaken. I'm running BeOpen Python
2.0, with the latest Pythonwin installed.

My problem - the os.listdir() command doesn't return
the name of the file in unicode, it just replaces the
hebrew characters with question marks - '?':

>>> l = os.listdir("c:\")
>>> l[-1]
'????.txt'
>>> type(l[-1])
<type 'string'>

Perhaps the os.listdir() function could be extended
with a unicode keyword, which would tell it to return
the filenames as unicode strings?

	filenames = os.listdir(path, unicode=1)



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

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


From nobody@sourceforge.net  Tue Feb 27 10:18:15 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 02:18:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-404545 ] frozen package import uses wrong files
Message-ID: <E14XhCx-0008L8-00@usw-sf-web2.sourceforge.net>

Artifact #404545, was updated on 2001-02-27 02:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404545&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Toby Dickenson
Assigned to: Nobody/Anonymous
Summary: frozen package import uses wrong files

Initial Comment:
In a frozen package, importing a module from 
another package causes the import machinery to try to 
open some curiously named files, before finally finding 
the frozen data.

It is possible to 'break' a frozen program by creating 
a file of that name. The frozen program will try to 
import from it rather than the frozen data.


The following collection of modules demonstrates this 
(also in the attached zip):

 Directory of D:\Projects\import

2001-02-27  08:57                   11 b.n.py
2001-02-27  08:49                   10 x.py
               2 File(s)             21 bytes

 Directory of D:\Projects\import\a

2001-02-27  08:57                   27 m.py
2001-02-27  09:58                    0 __init__.py
               2 File(s)             27 bytes

 Directory of D:\Projects\import\b

2001-02-27  08:56                   11 n.py
2001-02-27  09:58                    0 __init__.py
               2 File(s)             11 bytes

     Total Files Listed:
               6 File(s)             59 bytes
               0 Dir(s)   1,485,537,280 bytes free


The 'real' program is made up of the three files with 
single character names plus the two __init__ files.

b.n.py is a rogue file that breaks a frozen program.

x.py contains "import a.m"

a/m.py contains "import b.n". This is the import that 
goes wrong. When run as a normal script it imports 
b/n.py.

However, a frozen binary appears to search for various 
a.b.* files over sys.path first. If it is run from the 
same directory as a.b.py then it will load that file 
instead. Note that this file is not included in the 
freeze.



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

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


From nobody@sourceforge.net  Tue Feb 27 15:59:09 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 07:59:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-233592 ] Can't execute script from a DOS partition without .py ext
Message-ID: <E14XmWr-0001YE-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: Platform-specific
Status: Closed
Priority: 5
Submitted By: Skip Montanaro
Assigned to: Nobody/Anonymous
Summary: Can't execute script from a DOS partition without .py ext

Initial Comment:
I have a Python script without a .py extension on a DOS partition that runs fine using python 1.6 and 2.0, but fails with a syntax error on 2.1.  If I copy it back to a Linux ext2fs partition or give it a .py extension it works fine.  Diff thinks DOS and extfs versions are identical as does cksum.

    % python cgi-bin/query   
      File "cgi-bin/query", line 88
        print "serverdir could not be loaded"
        ^
    SyntaxError: invalid syntax

(Note that there are only 87 lines in the file.)

    % python cgi-bin/query.py
    Content-type: text/plain

    ...

I placed a copy of the script at

    http://www.musi-cal.com/~skip/query

Copying it from the DOS partition to the remote system using scp complained:

    query : ERROR..continuing to end of file anyway

This, coupled with the erroneous line number leads me to suspect the syntax error has to do with the presence of the DOS EOF marker.



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

Comment By: Skip Montanaro
Date: 2001-02-27 07:59

Message:
Logged In: YES 
user_id=44345

agreed - it's almost certainly something fishy on my system


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

Comment By: Tim Peters
Date: 2001-02-22 23:01

Message:
Is this unique to this script, or does it happen for any old Python script?  If the latter, can you come up with a minimal failing example?  If not, there's scant reason to believe this is a Python bug.

If scp complains when you copy it, doesn't that suggest this specific file is damaged in some way?

The DOS EOF marker is Ctrl-Z (Python chr(26)).

I observed one bizarre thing about the file I downloaded from your URL:

>>> f = open("query.txt", "rb")
>>> guts = f.read()
>>> list(guts).count(chr(0))
87
>>>

That is, it had 87 embedded null bytes, all at the end:

>>> guts[-87:] == chr(0) * 87
1
>>>

Beats me what that does!  It's not a legitimate text file, by C rules.  But then who knows whether I successfully downloaded what you posted ...

wc query.txt
    87     231    2273 query.txt

Is that what you get?  I can't imagine why scp would care about null bytes, though.

Face it, Skip:  your box is *hosed* <0.7 wink>.

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

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


From nobody@sourceforge.net  Tue Feb 27 17:05:29 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 09:05:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-232787 ] 2.1a1 compiler warnings under Solaris 8 with gcc
Message-ID: <E14XnZ3-00012M-00@usw-sf-web1.sourceforge.net>

Artifact #232787, was updated on 2001-02-16 17:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232787&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Mark Favas
Assigned to: Skip Montanaro
Summary: 2.1a1 compiler warnings under Solaris 8 with gcc

Initial Comment:
Platform: SunOS asafoetida 5.8 Generic_108528-04 sun4u sparc SUNW,Ultra-60
(actually a 220R server)
Compiler: gcc version 2.95.2 19991024 (release)
2.1a2: CVS version of Feb 16

The following compiler warnings are reported:

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Objects/floatobject.o Objects/floatobject.c
Objects/floatobject.c:35: warning: function declaration isn't a prototype

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Objects/intobject.o Objects/intobject.c
Objects/intobject.c: In function `PyInt_FromString':
Objects/intobject.c:185: warning: subscript has type `char'

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Python/errors.o Python/errors.c
Python/errors.c: In function `PyErr_Format':
Python/errors.c:405: warning: subscript has type `char'
Python/errors.c:460: warning: subscript has type `char'
Python/errors.c:465: warning: subscript has type `char'
Python/errors.c:468: warning: subscript has type `char'

gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  
-o Python/pythonrun.o Python/pythonrun.c
Python/pythonrun.c: In function `initsigs':
Python/pythonrun.c:1192: warning: function declaration isn't a prototype

gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H   
-c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_confstr':
./Modules/posixmodule.c:4524: warning: implicit declaration of function `confstr'

gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H   
-c ./Modules/signalmodule.c -o Modules/signalmodule.o
./Modules/signalmodule.c:88: warning: function declaration isn't a prototype
./Modules/signalmodule.c: In function `signal_signal':
./Modules/signalmodule.c:212: warning: function declaration isn't a prototype
./Modules/signalmodule.c:214: warning: function declaration isn't a prototype
./Modules/signalmodule.c:225: warning: function declaration isn't a prototype
./Modules/signalmodule.c: In function `initsignal':
./Modules/signalmodule.c:332: warning: function declaration isn't a prototype
./Modules/signalmodule.c:336: warning: function declaration isn't a prototype
./Modules/signalmodule.c:355: warning: function declaration isn't a prototype
./Modules/signalmodule.c:357: warning: function declaration isn't a prototype
./Modules/signalmodule.c: In function `finisignal':
./Modules/signalmodule.c:556: warning: function declaration isn't a prototype
./Modules/signalmodule.c:564: warning: function declaration isn't a prototype

<gcc compile lines omitted from here down>

Modules/stropmodule.c: In function `strop_atoi':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/stropmodule.c:752: warning: subscript has type `char'

Modules/timemodule.c: In function `time_strptime':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/timemodule.c:398: warning: subscript has type `char'

Modules/socketmodule.c: In function `PySocket_socket':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/socketmodule.c:1854: warning: function declaration isn't a prototype
/export/home0/mark/src/python/CVS/python/dist/src/Modules/socketmodule.c: In function `PySocket_fromfd':
/export/home0/mark/src/python/CVS/python/dist/src/Modules/socketmodule.c:1892: warning: function declaration isn't a prototype

In file included from /usr/include/curses.h:23,
from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/curses.h:5,
from Include/py_curses.h:8,
from Modules/_cursesmodule.c:104:
/usr/include/widec.h:38: warning: `getwc' redefined
/usr/include/iso/wchar_iso.h:337: warning: this is the location of the previous 
definition
/usr/include/widec.h:39: warning: `putwc' redefined
/usr/include/iso/wchar_iso.h:340: warning: this is the location of the previous 
definition
/usr/include/widec.h:40: warning: `getwchar' redefined
/usr/include/iso/wchar_iso.h:338: warning: this is the location of the previous 
definition
/usr/include/widec.h:41: warning: `putwchar' redefined
/usr/include/iso/wchar_iso.h:341: warning: this is the location of the previous 
definition
Modules/_cursesmodule.c: In function `PyCurses_Putp':
Modules/_cursesmodule.c:2135: 
warning: implicit declaration of function `putp'
Modules/_cursesmodule.c: In function `PyCurses_tigetflag':
Modules/_cursesmodule.c:2219: 
warning: implicit declaration of function `tigetflag'
Modules/_cursesmodule.c: In function `PyCurses_tigetnum':
Modules/_cursesmodule.c:2232: 
warning: implicit declaration of function `tigetnum'
Modules/_cursesmodule.c: In function `PyCurses_tigetstr':
Modules/_cursesmodule.c:2245: 
warning: implicit declaration of function `tigetstr'
Modules/_cursesmodule.c:2245: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c: In function `PyCurses_tparm':
Modules/_cursesmodule.c:2270: 
warning: implicit declaration of function `tparm'
Modules/_cursesmodule.c:2270: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2273: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2276: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2279: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2282: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2285: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2288: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2291: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2294: 
warning: assignment makes pointer from integer without a cast
Modules/_cursesmodule.c:2297: 
warning: assignment makes pointer from integer without a cast

In file included from /usr/include/curses.h:23,
from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include/curses.h:5,
from Include/py_curses.h:8,
from Modules/_curses_panel.c:15:
/usr/include/widec.h:38: warning: `getwc' redefined
/usr/include/iso/wchar_iso.h:337: warning: this is the location of the previous 
definition
/usr/include/widec.h:39: warning: `putwc' redefined
/usr/include/iso/wchar_iso.h:340: warning: this is the location of the previous 
definition
/usr/include/widec.h:40: warning: `getwchar' redefined
/usr/include/iso/wchar_iso.h:338: warning: this is the location of the previous 
definition
/usr/include/widec.h:41: warning: `putwchar' redefined
/usr/include/iso/wchar_iso.h:341: warning: this is the location of the previous 
definition
Modules/_curses_panel.c: In function `PyCursesPanel_set_panel_userptr':
Modules/_curses_panel.c:307: warning: passing arg 2 of `set_panel_userptr' from incompatible pointer type

Modules/fpectlmodule.c: In function `fpe_reset':
Modules/fpectlmodule.c:144: warning: implicit declaration of function `nonstandard_arithmetic'
Modules/fpectlmodule.c:145: warning: implicit declaration of function `ieee_flags'
Modules/fpectlmodule.c:146: warning: implicit declaration of function `ieee_handler'




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

Comment By: Skip Montanaro
Date: 2001-02-27 09:05

Message:
Logged In: YES 
user_id=44345

I took a look at these warnings.  Here's my summary.  Sorry
I can't be more helpful.  Is there someone else out there
with gcc on a Solaris system that can dig into these
warnings?

* floatobject.c - The code here should probably have a
tighter restriction - the comment suggests that it is only
for SUNOS 4.1, but the ifdef just says "#ifdef sun".  I've
no idea what the various version-related options are.

* various type `char' warnings - All these messages seem to
suggest a GCC wart in the isalnum macro.  I use 2.95.3 on my
Linux system but don't get these warnings.

* pythonrun.c - sure looks like a prototype to me.

* posixmodule.c - confstr is declared in <unistd.h> on my
system.  Looks like it's not included in this Solaris build
environment.  I will add the proper #ifdef and #include for
unistd.h to this file.

* signalmodule.c & socketmodule.c - GCC is complaining about
use of the fake signal handlers SIG_DFL, SIG_ERR and
SIG_IGN.  Again, I get no warnings on my Linux system using
GCC 2.95.3. 

* _cursesmodule.c & _curses_panel.c - There is a comment in
_cursesmodule.c about why <term.h> isn't included, then goes
on to declare a couple terminfo functions.  Those that are
implicitly declared here seem to be declared in curses.h and
ncurses.h, one of which is included in _cursesmodule.c I
think it's probably best to pass these off to ESR or someone
else with recent experience digging around in that module.

fpectlmodule.c - This is in a Sun-specific section of code. 
I don't see any of these symbols declared on my Linux
system.  The code suggests that the author expected them to
be declared in math.h.  They probably are declared when
using Sun's compiler, but not gcc.  I don't know what their
canonical definitions are, otherwise I'd insert some
declarations (their return types are all cast away to void). 

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

Comment By: Tim Peters
Date: 2001-02-23 11:28

Message:
Skip, you have time to look at this?  Most of them have to do with Unix-specific functions (i.e., I can't test them on my box, so don't want to change their source code).

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

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


From nobody@sourceforge.net  Tue Feb 27 19:18:02 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 11:18:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-229841 ] 'make install' needs write access to build directory
Message-ID: <E14XpdK-0003BE-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: None
Status: Closed
Priority: 5
Submitted By: Martin v. Löwis
Assigned to: A.M. Kuchling
Summary: 'make install' needs write access to build directory

Initial Comment:
[submitted by David Highley <dhighley@highley-recommended.com>]

I experienced the following types of installation build problems with the
Python 2.0 release. Not all building and modification of files is completed int the build step. When doing the install as a root user and the Python code tree is NFS mounted the install proess fails. I also needed to modify the Modules/Makefile to pass ld a run time path so that when the python executable is invoked it can find the tcl/tk libraries in /usr/local/lib. This install was on a Solaris 8 system.

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

Comment By: A.M. Kuchling
Date: 2001-02-27 11:18

Message:
Logged In: YES 
user_id=11375

I suspect this bug no longer applies to the current CVS, 
as the build process no longer increments buildno every time
you invoke make.


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

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


From nobody@sourceforge.net  Tue Feb 27 19:21:24 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 11:21:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-233334 ] --record option doesn't remove duplicate files
Message-ID: <E14Xpga-0003Cs-00@usw-sf-web3.sourceforge.net>

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

Category: Distutils
Group: None
Status: Closed
Priority: 5
Submitted By: Gerhard Häring
Assigned to: A.M. Kuchling
Summary: --record option doesn't remove duplicate files

Initial Comment:
If I invoke python setup.py install --record=INSTALLED_FILES and then feed the input of INSTALLED_FILES to RPM, RPM sometimes doesn't finish successfully because of duplicate files. It would be very nice if distutils would remove duplicate files from the recorded files itself.


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

Comment By: A.M. Kuchling
Date: 2001-02-27 11:21

Message:
Logged In: YES 
user_id=11375

This is fixed in the current CVS tree, and hence will 
be OK in 2.1beta1.  Revision 1.56 of commands/install.py 
patches the get_outputs() method to remove duplicated names.


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

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


From nobody@sourceforge.net  Tue Feb 27 19:26:34 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 11:26:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-229280 ] Weird build directory on BSDI
Message-ID: <E14Xpla-0003Fb-00@usw-sf-web3.sourceforge.net>

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

Category: Distutils
Group: None
Status: Closed
Priority: 5
Submitted By: A.M. Kuchling
Assigned to: A.M. Kuchling
Summary: Weird build directory on BSDI

Initial Comment:
Reported on python-dev by Thomas Wouters:
 I also noticed something funny: BSDI calls itself
'BSD/OS <version>', so distutils actually makes a directory called 'lib.bsd' and 'temp.bsd', with inside those a directory 'os-<version>-i386-2.1'. Is that a distutils bug, a setup.py bug, or intentional behaviour of one of the two ?

[I think this is a Distutils buglet; util.get_platform() should remove
weird characters from the output of uname. --amk]


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

Comment By: A.M. Kuchling
Date: 2001-02-27 11:26

Message:
Logged In: YES 
user_id=11375

Fixed in revision 1.61 of distutils/util.py.


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

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


From nobody@sourceforge.net  Tue Feb 27 19:42:44 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 11:42:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-232597 ] 2.1a2 compiler warnings on Compaq Tru64 Unix
Message-ID: <E14Xq1E-0004hZ-00@usw-sf-web2.sourceforge.net>

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

Category: Build
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Mark Favas
Assigned to: A.M. Kuchling
Summary: 2.1a2 compiler warnings on Compaq Tru64 Unix

Initial Comment:
2.1a2 from CVS of Feb 16 produces the following compiler warnings on Tru64
Unix (uname -a: OSF1 gonzo.per.dem.csiro.au V4.0 1229 alpha, Compaq C compiler, version: Compaq C V6.3-129 (dtk), Compiler Driver V6.3-126 (dtk)):

cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H  -o Python/ceval.o Python/ceval.c
cc: Info: Python/ceval.c, line 327: Trailing comma found in enumerator list. (trailcomma)
};


cc -O -Olimit 1500 -I. -I./Include -IInclude/ -I/usr/local/include -c Modules/_cursesmodule.c -o build/temp.osf1-V4.0-alpha-2.1/_cursesmodule.o
cc: Warning: Modules/_cursesmodule.c, line 632: In this statement, "derwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = derwin(self->win,nlines,ncols,begin_y,begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1287: In this statement, "subpad(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
    win = subpad(self->win, nlines, ncols, begin_y, begin_x);

cc: Warning: Modules/_cursesmodule.c, line 1517: In this statement, "termname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
NoArgReturnStringFunction(termname)

cc: Warning: Modules/_cursesmodule.c, line 1686: In this statement, "getwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
  win = getwin(PyFile_AsFile(temp));

cc: Warning: Modules/_cursesmodule.c, line 1954: In this statement, "keyname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
  knp = keyname(ch);

cc: Warning: Modules/_cursesmodule.c, line 2245: In this statement, "tigetstr(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
        capname = tigetstr( capname );

cc: Warning: Modules/_cursesmodule.c, line 2270: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt);

cc: Warning: Modules/_cursesmodule.c, line 2273: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1);

cc: Warning: Modules/_cursesmodule.c, line 2276: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2);

cc: Warning: Modules/_cursesmodule.c, line 2279: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3);

cc: Warning: Modules/_cursesmodule.c, line 2282: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4);

cc: Warning: Modules/_cursesmodule.c, line 2285: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5);

cc: Warning: Modules/_cursesmodule.c, line 2288: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6);

cc: Warning: Modules/_cursesmodule.c, line 2291: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7);

cc: Warning: Modules/_cursesmodule.c, line 2294: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8);

cc: Warning: Modules/_cursesmodule.c, line 2297: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
                result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8,i9);

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg1" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")

cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg2" is fetched but not initialized.  And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")






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

Comment By: A.M. Kuchling
Date: 2001-02-27 11:42

Message:
Logged In: YES 
user_id=11375

The get*yx() calls are always defined as macros.  This does
look like the correct curses.h header isn't  being picked
up.  Does Tru64's curses.h header require some magical
#define in order to work?

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-19 13:55

Message:
Looks like a different header may be needed to pick up the prototypes for many of these.  Assigned to the curses module guy.

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

Comment By: Thomas Wouters
Date: 2001-02-16 04:14

Message:
The first warning is my mistake. I thought I fixed that in a more recent version of my continue-inside-try patch, but apparently I didn't. Fixed in revision 2.230 of Python/ceval.c

The warnings in Modules/_cursusmodule.c are most likely caused by undefined functions, though why you don't see an error for those beats me. (undefined functions default to int-returning functions, so that's probably why you see those warnings.) 

The *other* warnings look damned legit, though, and the only reason they aren't is because getmaxyx and co. are (on the BSDI and Linux boxes I have acces to) defined as being macro calls, and in fact they *have* to be macro calls (or non-standard C calls) or they can't work. I'm not a curses expert, but I think an initialization is in place here (or just rewriting the silly macros so they make *sense* :-)


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

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


From nobody@sourceforge.net  Wed Feb 28 02:24:57 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 18:24:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-404774 ] nested scopes segfaults
Message-ID: <E14XwIT-0006Zr-00@usw-sf-web3.sourceforge.net>

Bugs #404774, was updated on 2001-02-27 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404774&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Gregory H. Ball
Assigned to: Nobody/Anonymous
Summary: nested scopes segfaults

Initial Comment:
In current CVS:

If a function was compiled with nested scopes
and with a name resolved in an outer scope, it
expects a cell object in the func_closure slot when
executed.

However the user can legally del f.func_closure.
Core dump follows next time the function is called.

 

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

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


From nobody@sourceforge.net  Wed Feb 28 02:27:17 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 18:27:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-404774 ] nested scopes segfaults
Message-ID: <E14XwKj-0007bN-00@usw-sf-web1.sourceforge.net>

Bugs #404774, was updated on 2001-02-27 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404774&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Gregory H. Ball
Assigned to: Nobody/Anonymous
Summary: nested scopes segfaults

Initial Comment:
In current CVS:

If a function was compiled with nested scopes
and with a name resolved in an outer scope, it
expects a cell object in the func_closure slot when
executed.

However the user can legally del f.func_closure.
Core dump follows next time the function is called.

 

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

Comment By: Gregory H. Ball
Date: 2001-02-27 18:27

Message:
Logged In: YES 
user_id=11365

I'm trying to upload a test case...

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

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


From nobody@sourceforge.net  Wed Feb 28 02:27:24 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 18:27:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-404774 ] nested scopes segfaults
Message-ID: <E14XwKq-0007bV-00@usw-sf-web1.sourceforge.net>

Bugs #404774, was updated on 2001-02-27 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404774&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Gregory H. Ball
Assigned to: Nobody/Anonymous
Summary: nested scopes segfaults

Initial Comment:
In current CVS:

If a function was compiled with nested scopes
and with a name resolved in an outer scope, it
expects a cell object in the func_closure slot when
executed.

However the user can legally del f.func_closure.
Core dump follows next time the function is called.

 

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

Comment By: Gregory H. Ball
Date: 2001-02-27 18:27

Message:
Logged In: YES 
user_id=11365

I'm trying to upload a test case...

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

Comment By: Gregory H. Ball
Date: 2001-02-27 18:27

Message:
Logged In: YES 
user_id=11365

I'm trying to upload a test case...

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

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


From nobody@sourceforge.net  Wed Feb 28 02:30:14 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 18:30:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-404774 ] nested scopes segfaults
Message-ID: <E14XwNa-0006cm-00@usw-sf-web3.sourceforge.net>

Bugs #404774, was updated on 2001-02-27 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404774&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Gregory H. Ball
Assigned to: Nobody/Anonymous
Summary: nested scopes segfaults

Initial Comment:
In current CVS:

If a function was compiled with nested scopes
and with a name resolved in an outer scope, it
expects a cell object in the func_closure slot when
executed.

However the user can legally del f.func_closure.
Core dump follows next time the function is called.

 

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

Comment By: Gregory H. Ball
Date: 2001-02-27 18:30

Message:
Logged In: YES 
user_id=11365

Here is the testcase:  (import this as a module 
e.g. test_scopes.py, since I'm not sure that from __future__
etc. works interactively yet.)

#test_scopes.py
from __future__ import nested_scopes

def make_closure():
    x=1
    def f():
        print 'x =', x
    return f

f=make_closure()
print f.func_closure
f()
del f.func_closure
print f.func_closure
f()


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

Comment By: Gregory H. Ball
Date: 2001-02-27 18:27

Message:
Logged In: YES 
user_id=11365

I'm trying to upload a test case...

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

Comment By: Gregory H. Ball
Date: 2001-02-27 18:27

Message:
Logged In: YES 
user_id=11365

I'm trying to upload a test case...

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

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


From nobody@sourceforge.net  Wed Feb 28 02:41:33 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 18:41:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-404774 ] nested scopes segfaults
Message-ID: <E14XwYX-0007oJ-00@usw-sf-web1.sourceforge.net>

Bugs #404774, was updated on 2001-02-27 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404774&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Closed
Priority: 5
Submitted By: Gregory H. Ball
Assigned to: Nobody/Anonymous
Summary: nested scopes segfaults

Initial Comment:
In current CVS:

If a function was compiled with nested scopes
and with a name resolved in an outer scope, it
expects a cell object in the func_closure slot when
executed.

However the user can legally del f.func_closure.
Core dump follows next time the function is called.

 

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

Comment By: Jeremy Hylton
Date: 2001-02-27 18:41

Message:
Logged In: YES 
user_id=31392

Gregory you are just plain sick <wink>.

I'll make the closure read-only, which is the only sensible
thing to do, particularly since the only reasonable thing
for them to contain is cells and you need C code to make a
cell.


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

Comment By: Gregory H. Ball
Date: 2001-02-27 18:30

Message:
Logged In: YES 
user_id=11365

Here is the testcase:  (import this as a module 
e.g. test_scopes.py, since I'm not sure that from __future__
etc. works interactively yet.)

#test_scopes.py
from __future__ import nested_scopes

def make_closure():
    x=1
    def f():
        print 'x =', x
    return f

f=make_closure()
print f.func_closure
f()
del f.func_closure
print f.func_closure
f()


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

Comment By: Gregory H. Ball
Date: 2001-02-27 18:27

Message:
Logged In: YES 
user_id=11365

I'm trying to upload a test case...

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

Comment By: Gregory H. Ball
Date: 2001-02-27 18:27

Message:
Logged In: YES 
user_id=11365

I'm trying to upload a test case...

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

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


From nobody@sourceforge.net  Wed Feb 28 05:46:08 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 21:46:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-404536 ] Bug in ConfigParser.py
Message-ID: <E14XzRA-0001NA-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Bug in ConfigParser.py

Initial Comment:
One problem is that both get() and read() switch the 
options to lower case (using 
ConfigParser.optionxform), but NONE of the other 
methods do this.
Basically what this means is that ConfigParser only 
works if you don't use any upper case in your option 
names, or you only use read() and get().

Another bug is in the remove_option() function.
It seams to me that there is a unreferenced 
variable "key".

Source code from ConfigParser.remove_option()

existed = sectdict.has_key(key)
        if existed:
            del sectdict[key]

To be able to use the function remove_option(), I had 
to change the variable "key" to "option" which is 
declared in the function header like this:

existed = sectdict.has_key(option)
        if existed:
            del sectdict[option]

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-27 21:46

Message:
Logged In: YES 
user_id=3066

Already fixed in CVS.

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

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


From nobody@sourceforge.net  Wed Feb 28 05:46:53 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 21:46:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-404535 ] Bug in ConfigParser.py
Message-ID: <E14XzRt-0001OQ-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Bug in ConfigParser.py

Initial Comment:
One problem is that both get() and read() switch the 
options to lower case (using 
ConfigParser.optionxform), but NONE of the other 
methods do this.
Basically what this means is that ConfigParser only 
works if you don't use any upper case in your option 
names, or you only use read() and get().

Another bug is in the remove_option() function.
It seams to me that there is a unreferenced 
variable "key".

Source code from ConfigParser.remove_option()

existed = sectdict.has_key(key)
        if existed:
            del sectdict[key]

To be able to use the function remove_option(), I had 
to change the variable "key" to "option" which is 
declared in the function header like this:

existed = sectdict.has_key(option)
        if existed:
            del sectdict[option]

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-27 21:46

Message:
Logged In: YES 
user_id=3066

Duplicate submission.

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

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


From nobody@sourceforge.net  Wed Feb 28 05:50:41 2001
From: nobody@sourceforge.net (nobody)
Date: Tue, 27 Feb 2001 21:50:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-404444 ] auto indent/parentheses
Message-ID: <E14XzVZ-0001Rb-00@usw-sf-web1.sourceforge.net>

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

Category: IDLE
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Charles Doutriaux
Assigned to: Tim Peters
Summary: auto indent/parentheses

Initial Comment:
It'd be really nice to have an automatic indent of a
line when using the "TAB" key anywhere on the line,
this feature exist in the python emacs mode and is
REALLY nice and a total time-saver.
Also, having the possibility to see which
parentheses/brackets you're closing while typing (as in
a lot of editors) would be really nice

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

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


From nobody@sourceforge.net  Wed Feb 28 09:50:26 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 01:50:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-404827 ] Python Makefile: LIBOBJS incorrect
Message-ID: <E14Y3Fa-00031f-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Python Makefile: LIBOBJS incorrect

Initial Comment:
The Makefile variable LIBOBJS holds the names of
objects which are needed as replacements for system
library routines missing on specific platforms
(e.g. strerror and memmove on SunOS4).

The sources for these objects reside in the Python
directory; the Makefile, however, expects the object
files in the main build directory.

The attached diff (which uses a gmake feature)
seams to fix the dependencies for these objects;
the "big final ar" command will take them from
the Python directory.

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

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


From nobody@sourceforge.net  Wed Feb 28 13:43:19 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 05:43:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-404875 ] setup.py problem with sunos4 (2.1)
Message-ID: <E14Y6sx-0002q9-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Detlef Lannert
Assigned to: Nobody/Anonymous
Summary: setup.py problem with sunos4 (2.1)

Initial Comment:
The current (2.1 CVS) setup.py file has a check for
platform == 'sunos4' (near line 399). If true, the
value '/usr/5include' is appended to include_dirs.
These, however, aren't initialized until much later
(near line 539).

Moving include_dirs = [] upwards before the sunos4
test helped in my case; setup.py worked as expected.


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

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


From nobody@sourceforge.net  Wed Feb 28 14:34:31 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 06:34:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-404899 ] testing uploads
Message-ID: <E14Y7gV-00076p-00@usw-sf-web1.sourceforge.net>

Bugs #404899, was updated on 2001-02-28 06:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404899&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Guido van Rossum
Assigned to: Nobody/Anonymous
Summary: testing uploads

Initial Comment:
testing uploads

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

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


From nobody@sourceforge.net  Wed Feb 28 14:35:29 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 06:35:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-404899 ] testing uploads
Message-ID: <E14Y7hR-00077w-00@usw-sf-web1.sourceforge.net>

Bugs #404899, was updated on 2001-02-28 06:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404899&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Guido van Rossum
Assigned to: Nobody/Anonymous
Summary: testing uploads

Initial Comment:
testing uploads

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

Comment By: Guido van Rossum
Date: 2001-02-28 06:35

Message:
Logged In: YES 
user_id=6380

upload file

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

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


From nobody@sourceforge.net  Wed Feb 28 14:36:36 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 06:36:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-404899 ] testing uploads
Message-ID: <E14Y7iW-0003Kb-00@usw-sf-web3.sourceforge.net>

Bugs #404899, was updated on 2001-02-28 06:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404899&group_id=5470

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Guido van Rossum
Assigned to: Nobody/Anonymous
Summary: testing uploads

Initial Comment:
testing uploads

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

Comment By: Guido van Rossum
Date: 2001-02-28 06:36

Message:
Logged In: YES 
user_id=6380

test 2

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

Comment By: Guido van Rossum
Date: 2001-02-28 06:35

Message:
Logged In: YES 
user_id=6380

upload file

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

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


From nobody@sourceforge.net  Wed Feb 28 14:37:23 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 06:37:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-404899 ] testing uploads
Message-ID: <E14Y7jH-0005P5-00@usw-sf-web2.sourceforge.net>

Bugs #404899, was updated on 2001-02-28 06:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404899&group_id=5470

Category: None
Group: None
Status: Deleted
Priority: 5
Submitted By: Guido van Rossum
Assigned to: Nobody/Anonymous
Summary: testing uploads

Initial Comment:
testing uploads

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

Comment By: Guido van Rossum
Date: 2001-02-28 06:36

Message:
Logged In: YES 
user_id=6380

test 2

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

Comment By: Guido van Rossum
Date: 2001-02-28 06:35

Message:
Logged In: YES 
user_id=6380

upload file

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

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


From nobody@sourceforge.net  Wed Feb 28 17:23:32 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 09:23:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-404827 ] Python Makefile: LIBOBJS incorrect
Message-ID: <E14YAK4-0006rF-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: Python Makefile: LIBOBJS incorrect

Initial Comment:
The Makefile variable LIBOBJS holds the names of
objects which are needed as replacements for system
library routines missing on specific platforms
(e.g. strerror and memmove on SunOS4).

The sources for these objects reside in the Python
directory; the Makefile, however, expects the object
files in the main build directory.

The attached diff (which uses a gmake feature)
seams to fix the dependencies for these objects;
the "big final ar" command will take them from
the Python directory.

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

Comment By: Detlef Lannert
Date: 2001-02-28 09:23

Message:
Logged In: YES 
user_id=70378

Dunno why the author should be "anonymous". I believe
I was logged in when I submitted this.

Sorry, I forgot to mention that I'm referring to
Python 2.1 alpha (the CVS version).

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

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


From nobody@sourceforge.net  Wed Feb 28 18:55:39 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 10:55:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-404130 ] site.py sets sys.path incorrectly.
Message-ID: <E14YBlD-0001rq-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Don Rozenberg
Assigned to: Nobody/Anonymous
Summary: site.py sets sys.path incorrectly.

Initial Comment:
site.py appears to append the site-packages to the
END of sys.path.  I think it should be set after 
PYTHONPATH but before the standard places like

'/home/rozen/lib/python2.1',
'/home/rozen/lib/python2.1/plat-linux2',
'/home/rozen/lib/python2.1/lib-tk',
'/home/rozen/lib/python2.1/lib-dynload'.

How else can I install a new version of any of the
packages in the standard places without overwriting
or renaming them.

In particular, I am trying to use disutils to
distribute a version of _tkinter and Tkinter.py; they
get placed in site-packages, which I think is the
correct place, but they don't get executed because the
usual suspects are searched first.

I guess that I can force the issue by setting the
PYTHONPATH, but I don't know how to do that from
distutils.  And that is not an answer.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 10:55

Message:
Logged In: YES 
user_id=3066

The decision not to allow easy overriding of standard modules is deliberate; this is done to protect the interpreter from accidental name conflicts and the like.

Closed as "Not a Bug".

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

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


From nobody@sourceforge.net  Wed Feb 28 19:09:20 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 11:09:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-233450 ] 2.1a2: make install fails for _tkinter
Message-ID: <E14YByS-00022B-00@usw-sf-web1.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Priority: 6
Submitted By: Konrad Hinsen
Assigned to: A.M. Kuchling
Summary: 2.1a2: make install fails for _tkinter

Initial Comment:
System: RedHat Linux 6.2

I did a straightforward build/install in my home directory (--prefix=$HOME), enabling the Tkinter module in Modules/Setup. During "make install", install complains that it can't create the directory $HOME/lib/python2.1/lib-dynload/Modules. Inspection of the top-level Makefile shows

SHAREDMODS= Modules/_tkinter$(SO)

which looks like the cause of the problem.


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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 11:09

Message:
Logged In: YES 
user_id=3066

This appears related to the change to use distutils to build library components where possible.  Assigned to Andrew since he's the expert for that change.

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

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


From nobody@sourceforge.net  Wed Feb 28 19:13:02 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 11:13:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-404539 ] os.listdir() can't grok Unicode filename
Message-ID: <E14YC22-00024x-00@usw-sf-web1.sourceforge.net>

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

Category: Unicode
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Itamar S.T.
Assigned to: Tim Peters
Summary: os.listdir() can't grok Unicode filename

Initial Comment:
I have a file whose name is part Hebrew, part English
on my W2K VMware install. Filenames on Win2000 are
Unicode, if I'm not mistaken. I'm running BeOpen Python
2.0, with the latest Pythonwin installed.

My problem - the os.listdir() command doesn't return
the name of the file in unicode, it just replaces the
hebrew characters with question marks - '?':

>>> l = os.listdir("c:\")
>>> l[-1]
'????.txt'
>>> type(l[-1])
<type 'string'>

Perhaps the os.listdir() function could be extended
with a unicode keyword, which would tell it to return
the filenames as unicode strings?

	filenames = os.listdir(path, unicode=1)



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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 11:13

Message:
Logged In: YES 
user_id=3066

Tim, are you familiar with the directory searching functions under Windows?  Can you determine the right thing to do?

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

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


From nobody@sourceforge.net  Wed Feb 28 19:26:30 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 11:26:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-233668 ] install-sh has no -d option but 2.1a2 Makefile uses it
Message-ID: <E14YCF4-0002FH-00@usw-sf-web1.sourceforge.net>

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

Category: Installation
Group: None
Status: Open
Priority: 7
Submitted By: Marc W. Mengel
Assigned to: Fred L. Drake, Jr.
Summary: install-sh has no -d option but 2.1a2 Makefile uses it

Initial Comment:
The install-sh script has no -d option to make directories, but the
Makefile attempts to use such an option on OSF1.  I suggest the
following patch:

*** install-sh.python.orig	Thu Feb 22 15:42:30 2001
--- install-sh.python.new	Thu Feb 22 15:39:49 2001
***************
*** 25,30 ****
--- 26,32 ----
  chownprog="${CHOWNPROG-chown}"
  chgrpprog="${CHGRPPROG-chgrp}"
  stripprog="${STRIPPROG-strip}"
+ mkdirprog="${MKDIRPROG-mkdir}"
  rmprog="${RMPROG-rm}"
  
  instcmd="$mvprog"
***************
*** 58,63 ****
--- 60,73 ----
  	    shift
  	    continue;;
  
+ 	-d) mkdircmd="$mkdirprog"
+ 	    chmodcmd="$chmodprog $2"
+ 	    instcmd=":"
+ 	    src="."
+ 	    shift
+ 	    shift
+ 	    continue;;
+ 
  	-s) stripcmd="$stripprog"
  	    shift
  	    continue;;
***************
*** 106,111 ****
--- 116,122 ----
  
  # and set any options; do chmod last to preserve setuid bits
  
+ if [ x"$mkdircmd" != x ]; then $doit $mkdircmd $dsttmp; fi
  if [ x"$chowncmd" != x ]; then $doit $chowncmd $dsttmp; fi
  if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dsttmp; fi
  if [ x"$stripcmd" != x ]; then $doit $stripcmd $dsttmp; fi


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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 11:26

Message:
Logged In: YES 
user_id=3066

I *think* this has been fixed already.

The install-sh script has been updated since the version you are working with.  Please test with the CVS version of install-sh (let me know if you want me to email it to you).

Thanks!

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

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


From nobody@sourceforge.net  Wed Feb 28 19:29:21 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 11:29:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-404539 ] os.listdir() can't grok Unicode filename
Message-ID: <E14YCHp-0007xJ-00@usw-sf-web2.sourceforge.net>

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

Category: Unicode
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Itamar S.T.
Assigned to: Mark Hammond
Summary: os.listdir() can't grok Unicode filename

Initial Comment:
I have a file whose name is part Hebrew, part English
on my W2K VMware install. Filenames on Win2000 are
Unicode, if I'm not mistaken. I'm running BeOpen Python
2.0, with the latest Pythonwin installed.

My problem - the os.listdir() command doesn't return
the name of the file in unicode, it just replaces the
hebrew characters with question marks - '?':

>>> l = os.listdir("c:\")
>>> l[-1]
'????.txt'
>>> type(l[-1])
<type 'string'>

Perhaps the os.listdir() function could be extended
with a unicode keyword, which would tell it to return
the filenames as unicode strings?

	filenames = os.listdir(path, unicode=1)



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

Comment By: Tim Peters
Date: 2001-02-28 11:29

Message:
Logged In: YES 
user_id=31435

Assigned to MarkH in case he has a clue.  The core Python 
code doesn't know about any of MS's TCHAR-related tricks 
(it uses plain 8-bit C strings everywhere).

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 11:13

Message:
Logged In: YES 
user_id=3066

Tim, are you familiar with the directory searching functions under Windows?  Can you determine the right thing to do?

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

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


From nobody@sourceforge.net  Wed Feb 28 19:30:18 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 11:30:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-232619 ] 2.1a2 misleading comment from "make install" (minor nit)
Message-ID: <E14YCIk-0002IG-00@usw-sf-web1.sourceforge.net>

Bugs #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
Priority: 5
Submitted By: Mark Favas
Assigned to: A.M. Kuchling
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: Fred L. Drake, Jr.
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 nobody@sourceforge.net  Wed Feb 28 19:41:39 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 11:41:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-404328 ] struct.calcsize returns wrong size
Message-ID: <E14YCTj-0002Ql-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: struct.calcsize returns wrong size

Initial Comment:
struct.calcsize returns the wrong size because it takes
into account the alignment of the type.
I needed to read a 56 packed structure and then write
it back.
Python insists that it needs 62 bytes for the fmt
'chl6s20schdhdh'

Using Python-2.1a2 source code I can get the correct
answer by
commenting out in Modules/structmodule.c
        if (e == NULL)
            return -1;
        itemsize = e->size;
-->  //size = align(size, c, e);
        x = num * itemsize; 
        size += x;

Basically packing in a string doesn't require any
alignment. The alignment is neccesary once unpacking
takes place. However if the unpacking is done to a
local c variable then the alignment should not be a
problem e.g.

long Unpack_long(char * offset)
{
long value;
	memcpy(&value,offset,sizeof(long);
	return value;
}

Regards Rene de Zwart

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 11:41

Message:
Logged In: YES 
user_id=3066

This is documented behavior of the struct module, not a bug.  The purpose of the module is to allow packing and unpacking of C structures; I don't know of any that exhibits the alignment behavior that you describe -- C "short" values are aligned to sizeof(short) boundaries.

If your C compiler is exhibiting different behavior, look to see if you're using compiler options that affect the packing of structures -- this is not "normal" behavior.

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

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


From nobody@sourceforge.net  Wed Feb 28 19:42:12 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 11:42:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-233450 ] 2.1a2: make install fails for _tkinter
Message-ID: <E14YCUG-0002RP-00@usw-sf-web1.sourceforge.net>

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

Category: Build
Group: None
Status: Closed
Priority: 6
Submitted By: Konrad Hinsen
Assigned to: A.M. Kuchling
Summary: 2.1a2: make install fails for _tkinter

Initial Comment:
System: RedHat Linux 6.2

I did a straightforward build/install in my home directory (--prefix=$HOME), enabling the Tkinter module in Modules/Setup. During "make install", install complains that it can't create the directory $HOME/lib/python2.1/lib-dynload/Modules. Inspection of the top-level Makefile shows

SHAREDMODS= Modules/_tkinter$(SO)

which looks like the cause of the problem.


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

Comment By: A.M. Kuchling
Date: 2001-02-28 11:42

Message:
Logged In: YES 
user_id=11375

The build machinery underwent massive revisions after 2.1a2,
and this no longer seems to be a problem.  (In fact Makefile
no longer defines SHAREDMODS at all.)

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 11:09

Message:
Logged In: YES 
user_id=3066

This appears related to the change to use distutils to build library components where possible.  Assigned to Andrew since he's the expert for that change.

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

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


From nobody@sourceforge.net  Wed Feb 28 19:44:33 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 11:44:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-404875 ] setup.py problem with sunos4 (2.1)
Message-ID: <E14YCWX-0002Sa-00@usw-sf-web1.sourceforge.net>

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

Category: Build
Group: None
Status: Open
Priority: 5
Submitted By: Detlef Lannert
Assigned to: A.M. Kuchling
Summary: setup.py problem with sunos4 (2.1)

Initial Comment:
The current (2.1 CVS) setup.py file has a check for
platform == 'sunos4' (near line 399). If true, the
value '/usr/5include' is appended to include_dirs.
These, however, aren't initialized until much later
(near line 539).

Moving include_dirs = [] upwards before the sunos4
test helped in my case; setup.py worked as expected.


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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 11:44

Message:
Logged In: YES 
user_id=3066

Andrew, this looks easy to fix, but you know the code better than I.

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

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


From nobody@sourceforge.net  Wed Feb 28 19:51:22 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 11:51:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-404875 ] setup.py problem with sunos4 (2.1)
Message-ID: <E14YCd8-00061T-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: None
Status: Closed
Priority: 5
Submitted By: Detlef Lannert
Assigned to: A.M. Kuchling
Summary: setup.py problem with sunos4 (2.1)

Initial Comment:
The current (2.1 CVS) setup.py file has a check for
platform == 'sunos4' (near line 399). If true, the
value '/usr/5include' is appended to include_dirs.
These, however, aren't initialized until much later
(near line 539).

Moving include_dirs = [] upwards before the sunos4
test helped in my case; setup.py worked as expected.


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

Comment By: A.M. Kuchling
Date: 2001-02-28 11:51

Message:
Logged In: YES 
user_id=11375

Fixed in rev. 1.32 of setup.py.


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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 11:44

Message:
Logged In: YES 
user_id=3066

Andrew, this looks easy to fix, but you know the code better than I.

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

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


From nobody@sourceforge.net  Wed Feb 28 19:51:48 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 11:51:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-404328 ] struct.calcsize returns wrong size
Message-ID: <E14YCdY-000621-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Nobody/Anonymous
Summary: struct.calcsize returns wrong size

Initial Comment:
struct.calcsize returns the wrong size because it takes
into account the alignment of the type.
I needed to read a 56 packed structure and then write
it back.
Python insists that it needs 62 bytes for the fmt
'chl6s20schdhdh'

Using Python-2.1a2 source code I can get the correct
answer by
commenting out in Modules/structmodule.c
        if (e == NULL)
            return -1;
        itemsize = e->size;
-->  //size = align(size, c, e);
        x = num * itemsize; 
        size += x;

Basically packing in a string doesn't require any
alignment. The alignment is neccesary once unpacking
takes place. However if the unpacking is done to a
local c variable then the alignment should not be a
problem e.g.

long Unpack_long(char * offset)
{
long value;
	memcpy(&value,offset,sizeof(long);
	return value;
}

Regards Rene de Zwart

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

Comment By: Tim Peters
Date: 2001-02-28 11:51

Message:
Logged In: YES 
user_id=31435

If he doesn't want native alignment, there are 4 format 
codes documented that use "standard" (i.e., no) alignment 
instead.

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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 11:41

Message:
Logged In: YES 
user_id=3066

This is documented behavior of the struct module, not a bug.  The purpose of the module is to allow packing and unpacking of C structures; I don't know of any that exhibits the alignment behavior that you describe -- C "short" values are aligned to sizeof(short) boundaries.

If your C compiler is exhibiting different behavior, look to see if you're using compiler options that affect the packing of structures -- this is not "normal" behavior.

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

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


From nobody@sourceforge.net  Wed Feb 28 20:16:09 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 12:16:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-404240 ] time_t  can be unsigned
Message-ID: <E14YD17-0002sc-00@usw-sf-web1.sourceforge.net>

Bugs #404240, was updated on 2001-02-25 23:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404240&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Priority: 5
Submitted By: Uwe Zessin
Assigned to: Nobody/Anonymous
Summary: time_t  can be unsigned

Initial Comment:
On recent versions of OpenVMS, time_t is defined as:

SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]TIME.H;1

     typedef unsigned long int time_t;


The compiler's complaint is as follows:

        if (mtime == -1)
............^
%CC-I-QUESTCOMPARE1, In this statement, the unsigned
 expression "mtime" is being compared with an equality
 operator to a constant whose value is negative.  This
 might not be what you intended.
at line number 715 in file IMPORT.C


>>> import time
>>> time.ctime(0x7fffffff)
'Tue Jan 19 03:14:07 2038'
>>> time.ctime(0x80000000)
'Tue Jan 19 03:14:08 2038'
>>> time.ctime(0xfffffffe)
'Sun Feb  7 06:28:14 2106'
>>> time.ctime(0xffffffff)
'Sun Feb  7 06:28:15 2106'
>>>


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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 12:16

Message:
Logged In: YES 
user_id=3066

What does OpenVMS use for an "invalid" value for the time_t type?  Where can we find more specific information about this issue for OpenVMS?

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

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


From nobody@sourceforge.net  Wed Feb 28 20:19:11 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 12:19:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-232786 ] 2.1a2 "make test" failures under Solaris 8
Message-ID: <E14YD43-0002vE-00@usw-sf-web1.sourceforge.net>

Bugs #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: Unicode
Group: None
Status: Open
Priority: 5
Submitted By: Mark Favas
Assigned to: M.-A. Lemburg
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.
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
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 nobody@sourceforge.net  Wed Feb 28 20:24:28 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 12:24:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-232786 ] 2.1a2 "make test" failures under Solaris 8
Message-ID: <E14YD9A-0002yn-00@usw-sf-web1.sourceforge.net>

Bugs #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: Open
Priority: 5
Submitted By: Mark Favas
Assigned to: Fred L. Drake, Jr.
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.
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.
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
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 nobody@sourceforge.net  Wed Feb 28 21:49:24 2001
From: nobody@sourceforge.net (nobody)
Date: Wed, 28 Feb 2001 13:49:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-233041 ] ftplib close() shouldn't delete self.sock, self.file
Message-ID: <E14YETM-00040a-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Not a Bug
Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous
Assigned to: Fred L. Drake, Jr.
Summary: ftplib close() shouldn't delete self.sock, self.file

Initial Comment:
In FTP.__init__ it does:
		self.sock = None
		self.file = None

But in FTP.__close__ it does:
	def close(self):
		'''Close the connection without assuming anything about it.'''
		self.file.close()
		self.sock.close()
		del self.file, self.sock

This seems wrong -- instead of "del self.file, self.sock", shouldn't it be "self.file = self.sock = None"?

This is a bug if only for the reason that it can lead to errors being thrown that are not in ftplib.all_errors (i.e. an AttributeError).


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

Comment By: Fred L. Drake, Jr.
Date: 2001-02-28 13:49

Message:
Logged In: YES 
user_id=3066

ftplib.all_errors is a list of FTP-related errors, not all errors that the code could conceivably raise.  This is not a bug.

On the other hand, a change similar to the one you describe was added in Lib/ftplib.py revision 1.52, but for a different reason (to allow close to be called more than once).

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

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